Arztbrief 2013

{{{Title}}}

Arztbrief 2013

Implementierungsleitfaden

vorgelegt von:
HL7-Deutschland

in Arbeit

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

Copyright © 2013: HL7 Deutschland

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

Kontributoren
	Agfa HealthCare GmbH	Bonn
100px	Heitmann Consulting & Services GmbH	Hürth
	brightOne GmbH	Köln

Dokumenteninformationen

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

Impressum

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

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

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

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 .

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 .

Einleitung

Motivation

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

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

Zielgruppe

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

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

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

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

Dokumente im Gesundheitswesen

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

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

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

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

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

Abgrenzung

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

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

Hilfreich ist in diesem Zusammenhang das IHE-Cookbook.

Aufbau dieses Implementierungsleitfadens

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

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

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

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

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

Grundlagen

HL7 Version 3 Referenz-Modell als Grundlage für CDA

Grundlage des Clinical Document Architecture (CDA) ist ein umfangreiches Objektmodell, das sogenannte Reference Information Model (RIM).

Allen Modellen bei HL7 Version 3 liegt das so genannte Referenz-Informations-Modell (RIM) zugrunde. Es beschreibt generisch zum Beispiel einen Behandlungsprozess. Dabei wird von einer Aktivität (Act) ausgegangen, an der Entitäten (z. B. Personen) in bestimmten Rollen (Arzt, Patient, Angehöriger) teilnehmen (Participation). Aktivitäten können miteinander in Beziehung (Kontext) stehen (Act Relationship), beispielsweise eine Laboranforderung und das daraus folgende Resultat. In der folgenden Abbildung sind die Basisklassen des RIM wiedergegeben. Darunter sind im Gesamt-RIM natürlich noch Spezialisierungen der Klassen zu finden. So ist eine Diagnose ein Sonderfall einer Beobachtung, diese wiederum eine Aktivität.

RIM Basisklassen

Diese Basisklassen erfahren - als Beispiel - folgende Spezialisierungen, die auch in diesem Leitfaden verwendet werden:

• entity
  • Person
  • Organisation
  • Gerät
• role
  • beabsichtigter Empfänger
  • verwaltende Organisation
  • Pate
  • ...
• participation
  • Patient
  • Autor
  • Informant
  • sonstiger Beteiligter
    • Hausarzt
    • ...
• act
  • Beobachtung
    • Diagnose
  • Maßnahme
  • ..

HL7 CDA basiert komplett auf HL7 Version 3, so dass dessen Verständnis hilfreich ist.

Vorgehensweise

Diese Spezifikation basiert auf den umfangreichen Diskussionen innerhalb der Arbeitsgruppe „Intersektorale Kommunikation" und wurde ergänzt durch Einschränkung bzw. Konkretisierung bestehender nationaler und internationaler Implementierungsleitfäden, namentlich

• „Sciphox Arztbrief" (gemäß WD 15)
• HL7 v3 , CDA Rel. 2 „CDA Care Record Summary Implementation Guide"
• Use Cases for Medical Summaries, L. McNight, IHE PCC, 2005
• Der französische „Guide d’implémentation du Volet Médical au format CDA Release 2 – Niveau 3"
• e-MS. Implementierungsleitfaden CDA (Level 2 und 3), Kanada
• IHE Laboratory Technical Framework, Supplement „Sharing Laboratory Reports (XDS-LAB)"
• CDA-Leitfäden der ELGA GmbH, Wien (Österreich)
• CDA-Leitfäden von HL7 Schweiz

und schließlich als Zusatzdokument mit entsprechenden Mechanismen formal festgelegt.

Als Fernziel sei auch der Einsatz von HL7-Tools erwähnt, mit dem derartige Festlegungen auch automatisch aus formalen Ausdrücken der CDA Refined Message Information Model (R-MIM) Constraints abgeleitet werden können. Der dazu benötigte HL7-Template-Formalismus - derzeit noch als Teil von HL7v3 in Entwicklung – wird einen eindeutigen Generierungspfad vom Reference Information Model (RIM) bis zu den Validierungsausdrücken und Constraints festlegen. Damit könnten Schemata algorithmisch aus den modell-bezogenen Templates auf die gleiche Weise generiert werden, wie auch das allgemeine CDA-Schema aus seinem R-MIM generiert wurde.

Die Festlegungen in diesem Dokument werden formal durch XSD-Schemas formuliert. Die Schemas sind originaler CDA Release 2 Standard.

Zertifizierung

Die Verwendung des Implementierungsleitfadens in Softwareprodukten ist grundsätzlich frei von jeglicher Zertifizierung.

Stabilität der verwendeten Standards

Standards in der Medizin, so auch Kommunikationsstandards, entwickeln sich kontinuierlich weiter, um den ständig ändernden Anforderungen gerecht zu werden. Allerdings ist eine kontinuierliche Weiterentwicklung in Bezug auf reale Implementierungen nicht handhabbar.

Deshalb wählt man zu einem gegebenen Zeitpunkt, im Sinne einer Momentaufnahme, die zu verwendenden Standards aus und „friert" diesen für eine Zeit lang ein. Das heißt für diesen Leitfaden, dass in Bezug auf die verwendeten Standards stabile Verhältnisse für etwa zwei Jahre zu erwarten sind.

HL7 konstatiert zudem die Möglichkeit, dass Versionen, die zum Beispiel auf unterschiedlichen Implementation Technology Specifications (ITS) beruhen, durch „einfache" Transformationen (z. B. mittels XSLT) ineinander überführbar sind.

CDA Release 2 (CDA R2) ist ANSI Standard seit Mai 2005. Dieser Leitfaden fußt auf ANSI/HL7 CDA R2-2005, derweil gehen die Entwicklungen bei CDA weiter, So ist derzeit (Sommer 2014) das Release 2.1 in Vorbereitung, eine verbesserte und leicht ergänzte Version von CDA R2. Viele (insbesondere internationale) Spezifikationen basieren auf CDA (zum Beispiel IHE PCC, ELGA, CDA-CH2). Implementierungen (so auch die auf diesem Leitfaden basierten) liefern kontinuierlich Verbesserungsvorschläge. So wurde in diesem Leitfaden auch intensiv Gebrauch vom Templatemechanismus gemacht, welcher insbesondere Entwicklern zugute kommt. In Summa kann festgehalten werden, dass damit CDA R2 der erfolgreichste HL7 Version 3 Standard ist.

Die verwendeten Datentypen sind mit den Festlegungen in „XML Implementation Technology Specification - Data Types Release 1" schon länger ANSI Standard (seit der Jahreswende 2004/05). Diese sind auch im Leitfaden "HL7 Version 3 Datentypen und CMETs Leitfaden für das Deutsche Gesundheitswesen" veröffentlicht.

Bezug zum HL7 Version 3 Nachrichtenaustausch

Das CDA-Informationsmodell stellt eine Beschreibung für die Nutzinhalte von medizinischen Dokumenten zur Verfügung. Dabei wird aber explizit kein Hinweis auf den elektronischen Informationsaustausch von CDA-Dokumenten gegeben.

Von Seiten HL7 wird dieses durch die Einbeziehung in das Nachrichtenkonzept von HL7 Version 3 vollzogen, insbesondere die abstrakten Transmission Informationen (Wrapper-Konstrukte) und weitere Infrastrukturelemente (u. a. Control Acts).

Damit ist eine Use-Case abhängige Koexistenz von medizinischen Dokumenten und Nachrichten-Konzepten sowie konkrete Einbindbarkeit von CDA in Nachrichtenabläufe gegeben. Dies stellt aus HL7-Sicht einen wichtigen Eckpfeiler für einen effizienten Austauschstandard im Gesundheitswesen dar.

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 Release 2 – Konzept und Modellbeschreibung

CDA und XML

Für XML als grundsätzliches Format spricht die Flexibilität nicht nur bei der Länge einzelner darzustellender Texte sondern auch bezüglich der a priori nicht begrenzten Schachtelungstiefe von Elementen.

HL7 als IT-Standard im Gesundheitswesen ist vornehmlich in Krankenhäusern verbreitet und wird zum Datenaustausch zwischen Abteilungssystemen eingesetzt. Der ursprünglich aus Amerika stammende Ansatz ist im Laufe der Zeit zu einem international einsetzbaren Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken. Mittlerweile wird HL7 in vielen Ländern konkret eingesetzt, ist in manchen Ländern sogar offizielle Norm. Dennoch wurde HL7 in Deutschland im niedergelassenen Bereich oder in der ambulant-stationären Kommunikation bisher nicht umgesetzt.

Zwischenzeitlich ist von der HL7-Organisation der Standard „HL7 v3" international entwickelt und anerkannt worden (bzw. abhängig von den Anwendungsdomänen noch in Verabschiedung und Anerkennung). HL7 v3 bietet:

• eine konzeptuelle Grundlage in einem gemeinsamen, umfassenden „Reference Information Model" (RIM) für alle Teile von HL7 v3; dieses RIM ist ANSI- und ISO-Standard
• ein festes semantisches Fundament in explizit definierten Konzept-Domänen
• ausgewählte standardisierte Terminologien, die in den Domänen semantische Interoperabilität garantieren
• die Trennung von Inhalten und Syntax (wenngleich die Verwendung bestimmter Elementnamen vor allem im Header eine gewisse Semantik suggerieren)
• eine technologie-unabhängige Entwurfsmethodik.

HL7 v3 basiert auf XML und wird genutzt für die Übermittlung von Nachrichten. HL7 stellt außerdem einen Standard zur Strukturierung, zum Inhalt und zum Austausch medizinischer Dokumente, der so genannten Clinical Document Architecture (CDA), zur Verfügung. Dabei steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund, ist also nicht beschränkt auf Krankenhäuser. Als Grundlage für die Dokumente wurde HL7 Version 3 CDA Release 2 gewählt.

CDA Standard

Die Clinical Document Architecture ist ein Standard für den Austausch und die Speicherung von klinischer Dokumentation, wie zum Beispiel ein Entlassbrief oder eine Überweisung, Behandlungsdokumentation oder OP-Berichte. Dabei wird die Extensible Markup Language XML benutzt. CDA wird entwickelt von HL7 (Health Level Seven), einer bedeutenden internationalen Organisation für die Entwicklung von IT-Standards für das Gesundheitswesen.

CDA ist eine Entwicklung innerhalb der HL7-Gruppe seit 1997 und stellt einen XML-basierten Dokumenten-Markup Standard zur strukturierten klinischen Dokumentation zur Verfügung. Es definiert ein Informationsobjekt, das außerhalb einer Nachricht existieren kann und neben (strukturiertem) Text auch Bilder, Töne, Biosignale usw. enthalten bzw. referenzieren kann. CDA ist Teil der so genannten „Familie" der HL7 Version 3 Standards. Die erste Version, CDA Release 1, konnte bereits im September 2000 als offizieller Standard verabschiedet werden (CDA Level One ANSI/HL7 CDA R1.0-2000). Damit galt CDA R1 als erster offizieller XML-basierter Standard im Gesundheitswesen. Mittlerweile wird Release 1 in unzähligen Projekten rund um die Welt genutzt. Auf zwei internationalen Konferenzen 2002 und 2004 wurden die verschiedenen Projekte dargestellt (siehe Proceedings ). Die Erfahrungen und weiter gehende Bedürfnisse sind in die Entwicklung von CDA Release 2 eingegangen.

CDA Release 2 als Fortentwicklung dieses Standards wurde, nach beinahe fünf Jahren weiterer Entwicklungsarbeit am Standard, im Juli 2005 zum ANSI Standard erhoben. In diese Entwicklungen sind zahlreiche Erfahrungen aus weltweit mehr als 15 größeren, teilweise nationenweiten Projekten eingeflossen, die sich intensiv um CDA Release 1 und der Weiterentwicklung verdient gemacht haben. Basierend auf dem HL7 Referenz-Informationsmodell (siehe oben) besteht CDA Release 2, grob gesprochen, aus Tags/Markup, die Semantik bereitstellen für Personen und Dokumenteneigenschaften (z. B. <patient>, <provider>, <authenticator>, etc.) und für die Abbildung von Dokumentenstrukturen und -hierarchien genutzt werden können (z. B. <section>, <paragraph>, <table>, etc.).

Der Name für dieses Konzept änderte sich – aus der ursprünglichen Kona-Architektur wurde die Patient Record Architecture und dann schließlich die Clinical Document Architecture – aber die Ideen dieser Architektur sind gleich geblieben.

Ein wichtiges Konzept in CDA ist das der Level, die a.a.O. weiter erläutert werden (siehe unten in diesem Leitfaden).

Eigenschaften von CDA Dokumenten

Im Standard werden sechs Kerneigenschaften definiert, die ein klinisches Dokument nach CDA kennzeichnen. Diese seien hier im Folgenden eingehender erläutert.

Persistenz

CDA Dokumente sind Persistenz, das heißt dauerhaft Existent in den sendenden oder empfangenden Systemen. Dies kennt man auch aus der Papierwelt (klinische Dokumentation hat „Dokumenten-Charakter").

Verantwortlichkeit für die Verwaltung des Dokuments

Eine Organisation ist verantwortlich für die Verwaltung eines CDA Dokuments.

Signaturfähigkeit

Ein CDA Dokument ist durch Informationen gekennzeichnet, die potentiell signiert werden können bzw. zur vor dem Gesetz gültigen Signatur benutzt werden können. (vgl. )

Kontext

Alle Informationen werden in Dokumenten in einen bestimmten Kontext gestellt. Ein Entlassbrief fasst z. B. alle Informationen der vorangegangenen Behandlungsepisode im Kontext der Entlassung zusammen. Diese Kontextbewahrung gilt für das ganze Dokument.

Ganzheit des Dokuments

Der Inhalt eines klinischen Dokuments bezieht sich immer auf das Dokument als Ganzes, Teilinformationen daraus können nicht ohne Bezug auf das Dokument verwendet werden.

Lesbarkeit (human readability)

Jedes CDA Dokument muss die klinischen Informationen in lesbarer Form enthalten. Diese Lesbarkeit der klinischen Inhalte für die menschlichen Kommunikationspartner ist dadurch gewährleistet, dass man diesen Anteil im XML Dokument mit sehr einfachen Mitteln (z. B. so genannte Stylesheets) sichtbar machen kann. Dies betrifft sowohl den CDA-Body als auch die strukturierten Informationen im CDA-Header. Dafür gilt zudem:

• Es muss einen deterministischen Weg für einen Empfänger geben, den authentifizierten Inhalt sichtbar, sprich für lesbar zu machen.
• Die Lesbarkeit sollte nicht beinhalten, dass ein bestimmtes Stylesheet zusammen mit dem CDA Dokument gesendet werden muss. Es muss möglich sein, den Inhalt mit einem geeigneten Stylesheet und marktüblichen Browsern darzustellen.
• Lesbarkeit bezieht sich auf den authentifizierten Inhalt. Zusätzlich kann weitere Information im Dokument vorhanden sein, die auf Auswertbarkeit durch Anwendungssysteme abzielt, die aber nicht lesbar dargestellt werden muss.
• Wenn strukturierter Inhalt vom narrativen Text abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde, z. B. durch den Autor, durch eine Person, die die Codes hinzugefügt hat, durch automatisierte Verarbeitung der natürliche Sprache, durch eine spezifische Software.
• Wenn narrativer Text von strukturierter Information abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde.

CDA Modellbeschreibung

Wie alle Spezifikationen von Nachrichten in HL7 basiert auch die Clinical Document Architecture auf dem RIM und ist als HL7 V3 Modell repräsentiert.

Grob gesprochen besteht ein CDA Dokument aus einem Header und einem Body, der wiederum Body Structures und CDA Entries aufweist. An die Entries können externe Referenzen (External References) geknüpft sein. Der folgende Überblick zeigt die Hauptkomponenten des CDA R2 Modells auf, in der Abbildung 3 ist das Ganze in XML-artiger Darstellung gezeigt.

Vereinfachte Übersicht über einen Teil des CDA Modells mit Clinical Document Header (Informationen über das Dokument sowie deren Beteiligte, einschließlich Patient), Body Structures (Abschnitte und narrativer Text), CDA Entries (maschinenauswertbare Detailinformationen). Schließlich können auch externe Referenzen aufgeführt sein.

Grober Aufbau eines CDA Dokuments aus XML Sicht.

CDA Header

Die Informationen zum Patienten, zum Dokument selbst, zu den weiteren beteiligten Personen und Organisationen sowie der dokumentierten Episode (Zeitereignisse) sind zum CDA Header zusammengefasst, hochstrukturiert und von der Semantik her festgelegt.

Die Informationen im Header unterstützen einen Austausch klinischer Dokumente über Institutionsgrenzen hinweg. Er trägt Informationen über das Dokument selbst (eine eineindeutige Identifikation, der Typ des Dokuments), über „Teilnehmer" am Dokument (an der Dokumentation beteiligte Heilberufler, Autoren, und natürlich den Patienten selbst), sowie über Beziehungen zu Dokumenten (zu Anforderungen und anderen Dokumenten). Mit den Informationen des Headers werden Dokumentenmanagement-Systeme unterstützt, der Header stellt dafür entsprechende Metadaten zur Verfügung. Schließlich hat man mit den im CDA Header verfügbaren Informationen die Zusammenführung einer individuellen (lebenslangen) Patientenakte vor Augen.

CDA Body

Die eigentliche klinische Dokumentation wird im so genannten CDA Body festgehalten. Im Vordergrund steht hier „lesbarer" (narrativer) Text, der verpflichtender Bestandteil von CDA R2 Dokumenten ist und die Interoperabilität zwischen den menschlichen Kommunikationspartnern garantiert.

Hier sind Möglichkeiten gegeben, diesen Text grob zu strukturieren, wie man dies von den Möglichkeiten der Textverarbeitung her kennt. Zur Strukturierung stellt die Standardspezifikation eine Reihe von XML-Elementen zur Verfügung, die als Body Structures zusammengefasst werden können. Der Body enthält ein oder mehrere Abschnitte (sections). Diese können auch ineinander geschachtelt sein, so wie Kapitel und Unterkapitel in einem Buch. Zudem sind Strukturierungen im Sinne von Tabellen oder Listen möglich.

• Abschnitte <section>
• Paragrafen <paragraph>
• Kennzeichnung von bestimmten Inhalten <content>
• Überschriften <caption>
• Tabellen <table>
• Listen <list>

Sections enthalten immer einen narrativen Block und erfüllen damit eine der oben genannten Maximen von CDA: die Mensch-zu-Mensch-Interoperabilität, die Lesbarkeit der Informationen für den Menschen. Im narrativen Block, durch das Textattribut in der section-Klasse repräsentiert, wird eingebetteter Text innerhalb eines Abschnittes angegeben. Dabei kann mit oben genanntem <content> Element bestimmter Inhalt gesondert gekennzeichnet werden. Zusammengefasst werden im Textblock (teils so auch schon in CDA Release 1 realisiert) u.a. folgende Möglichkeiten der Struktur- und Formgebung des fließenden Textes gegeben:

• Zeilenumbrüche
• Stilistische Angaben (unterstreichen, fett, kursiv etc.)
• Hoch- und Tiefstellung von Text
• Fußnoten
• Symbole
• Revisionsmarken im Text wie <delete>, <insert>

Mit den beschriebenen Body Strukturen können CDA Entries verbunden sein. Diese repräsentieren den „computerlesbaren Teil" innerhalb eines Dokumentenabschnitts. CDA Entries sind im Prinzip eine Auswahl aus Klassen mitsamt Attributen aus dem HL7 Referenz-Informationsmodell (RIM). In der folgenden Abbildung ist ein Ausschnitt daraus gezeigt.

Ausschnitt aus der Auswahlliste der CDA Body Entries mit Darstellung der HL7 RIM-Klassen und deren Attributen

Diese Auswahlliste von Aktivitäten wird auch als Clinical Statement Pattern bezeichnet und findet sich in gleicher oder ähnlicher Form auch in HL7-Version 3-Nachrichten zu Anforderungen und Befunden etc. wieder. Eine konkrete Ausprägung davon wird dann als Clinical Statement bezeichnet. In dieser Auswahl sind folgende Klassen verfügbar:

• observation, eine (kodierte) Beobachtung, z. B. ein Befund oder eine Diagnose
• procedure, eine Prozedur, z. B. eine Operation, eine andere Behandlung, rein diagnostischer Eingriff
• encounter, Angaben zu früheren, jetzigen oder geplanten Patientenkontakten
• substanceAdministration, medikamenten-bezogene Angaben im Sinne von stattgefundenen (Medikamentenanamnese) oder geplanten Medikamentengaben
• supply, zur Verfügungstellung von Material oder Medikamentenverabreichungen
• organizer, zur Gruppierung von anderen CDA Entries (Batterien, Cluster)
• observationMedia, multimedialer Inhalt als Teil des Dokuments
• regionOfInterest, Kennzeichnung einer Hervorhebung eines Teilaspekts eines Bildes.

Alle diese Entries können untereinander linear oder rekursiv hierarchisch verbunden sein. Es sind gleichstufige Beziehungen möglich (zum Beispiel eine Liste von Beobachtungen), aber auch die Wiedergabe einer Hierarchie (z. B. „kleines Blutbild", bestehend aus „Erythrozyten", „Leukozyten",...).

Die folgende Abbildung zeigt das ganz CDA Release 2 Modell.

Clinical Document Architecture Release 2.0

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 .

Konzept der Templates

Wie aus den vorhergehenden Erläuterungen ersichtlich ist, setzt sich ein Dokument aus verschiedenen Komponenten zusammen, die flexibel miteinander kombiniert werden können. Für ein Zusammensetzen der Einzelteile auf den unterschiedlichen Ebenen gibt es detaillierte „Baupläne“, die in CDA auch Templates – oder Schablonen oder auch Muster – genannt werden.

Es werden die folgenden Template-Typen bei CDA unterscheiden.

Document Level Template

Angabe der benötigten Einzelteile für eine bestimmte Art von Dokument. So legt die Schablone für einen Arztbrief beispielsweise fest, dass ein Arzt das Dokument für einen anderen Arzt erstellt und somit sowohl eine Anrede und eine Grußformel enthalten sollte. Bei einem einfachen Meldebogen ist letzteres nicht der Fall.

Inhalt: Festlegung des Inhalts des Dokuments inklusive der Header und Section-Level-Templates sowie weiterer Header-Metadaten

Header Level Template

Angabe, wie die größeren Blöcke im Header eines Dokumentes konkret aussehen sollen, zum Beispiel welche Details zu einem Patienten hinterlegt werden können. Beispiele für Inhalt: Patient, Autor, Unterzeichner, weitere Beteiligte, ..

Section Level Template

Inhalt: Angabe, wie ein bestimmter Abschnitt konkret aussehen soll. Hier können auch Vorgaben gemacht werden, wie zum Beispiel Diagnosen in einer tabellarischen Form textuell aufbereitet werden sollen, damit sie einheitlich durch ein Stylesheet zur Anzeige gebracht werden können. Möglicherweise existieren passende Entry-Level-Templates zu der Sektion. Hier kann auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden.

Beispiele für Inhalt: Anrede, Diagnose, Maßnahme, ..

Entry Level Template

Angabe, wie die Einzelinformationen in struktierter und kodierter Form hinterlegt werden sollen, damit sie durch ein Programm ausgewertet und weiter verarbeitet werden können.

Beispiele für Inhalt: ICD-Diagnosen, Maßnahmen, Scores und Assessments, Meldeanlässe, ..

Datentypen

Hier handelt es sich genau genommen nicht um Templates, sondern um sog. „Datentypen-Flavors“, jedoch beschreiben diese wie ein Datentyp in einem bestimmten Use Case genutzt werden soll. So kann es beispielsweise zwei unterschiedliche Ausprägungen für Adressen geben, die vollständige Adresse lässt Straßennamen oder Postfächer zu, der Geburtsort wird auf die Stadt inklusive Land eingeschränkt. Diese Datentypen werden in den drei vorher genannten Arten von Templates genutzt.

Inhalt: Verwendung bei Namen, Adressen, Telefonnummern, ..

Profile Components

Templates stellen somit sog. „Profile Components“ dar, sind also selber konkrete Ausprägungen allgemeiner Vorgaben für einen bestimmten Use Case. Derartige Ausprägungen können hierarchisch vorgenommen werden. Nachfolgend sei das an einem Beispiel erläutert.

Stufe	Hierarchie / ID	Inhalt	Einschränkung
1	Author (HL7 International) 2.16.840.1.113883.10.12.102	Originäre Spezifikation aus dem CDA-Header	Keine
2	Author allgemein (HL7 Deutschland) 1.2.276.0.76.10.2002	Ausdifferenzierung inklusiver aller Details	Anwendung von Datentypen-Flavors
3	Author Person (HL7 Deutschland) 1.2.276.0.76.10.2007	Reduzierung auf eine Person als Autor	Streichung der Auswahlmöglichkeit
3	Author Gerät (HL7 Deutschland) 1.2.276.0.76.10.2008	Reduzierung auf ein Gerät als Autor	Streichung der Auswahlmöglichkeit

Beispiel für eine Template-Hierarchie

Eine weitere wichtige Eigenschaft ist die Feststellung, ob Templates „offen“ oder „geschlossen“ sind, d.h. ob nur die definierten Elemente zugelassen sind (geschlossen) oder ob auch Erweiterungen – gemäß dem zugrunde liegenden Modell – erlaubt sind (offen). Hier gibt es unterschiedliche Vorgehensweisen. So macht es für die Angaben im Header durchaus Sinn, alle notwendigen Details soweit vorzugeben, so dass in Spezialisierungen bei nicht benötigten Attributen/Klassen nur die entsprechenden Auswahlmöglichkeiten gestrichen werden müssen, während für die Angaben im Body nur bedingt möglich ist, alle Eventualitäten vorzugeben.

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 .

Konformität

Ein zu diesem Implementierungsleitfaden (engl. Implementation Guide) konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein konformer "stationärer Entlassbrief" kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäftsregeln" im weiteren Text dieses Dokuments.

Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten (und Nachrichten) wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das zum Arztbrief gehörige Schema ist das unveränderte generische, offizielle CDA Release 2 Schema (siehe Anhang). Darüber hinaus sind eine Reihe von Schematron Skripts denkbar (und im Rahmen dieses Leitfadens auch erstellt), die für einen zweiten „Validierungsschritt" genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben sowie die Einhaltung der Geschäftsregeln sicherstellen können. Diese Schritte werden auch als Templates bezeichnet, allgemeine Arbeiten zu diesem Thema sind zurzeit in Gange, jedoch noch nicht abgeschlossen, so dass wir hier auf bewährte Techniken (W3C Schema und Schematron) zurückgreifen. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt, oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiger Arztbrief im Sinne dieses Implementierungsleitfadens.

Die hier verwendeten Constraints basieren zum Teil auf extern kontrollierten Vokabularen, die sich nach Verabschiedung dieses Implementierungsleitfadens ändern könnten.

CDA ermöglicht die Identifikation der verwendeten Templates mithilfe eines eindeutigen Identifikators. Der Einsatz von so genannten „templateId" Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA-konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit Zusicherung ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.

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

Transportaspekte

Interaktionsdiagramm

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

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

Interaktionsdiagramm

Dokumentenaustausch

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

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

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

Rechtssichere Übertragung

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

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

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

Struktureller Aufbau

Das statische Modell umfasst

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

Grober XML-Aufbau von CDA-Dokumenten

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

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

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

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

Templates für den Arztbrief

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

Ü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)

Informationen über die verschiedenen Beteiligten und Aktivitäten

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 .

Patient (recordTarget - generisch)

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

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 .

Participant: Informant (informant)

Id	1.2.276.0.76.10.2018	Gültigkeit	2014‑08‑25
Status	Entwurf	Versions-Label
Name	CDAinformant	Bezeichnung	CDA Informant
Beschreibung	Informant, Personen, die Informationen zu dem Arztbrief beigesteuert haben (i.d.R. natürliche Personen, die nicht als Leistungserbringer agieren)
Klassifikation	CDA Header Level Template CDA Entry 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.90012 Inklusion CDA Assigned Entity Elements DYNAMIC 1.2.276.0.76.10.90020 Inklusion RelatedEntity (Body) DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.319 CDA Informant (Body) (2005‑09‑07) ref ad1bbr-
Beispiel	Beispiel <informant typeCode="INF">   <assignedEntity>     <id extension="4342116437" root="2.16.840.1.113883.3.933"/>    <assignedPerson>       <name>         <prefix>Dr. </prefix>        <given>Ursula</given>        <family>Müller</family>      </name>    </assignedPerson>  </assignedEntity></informant>
Beispiel	Beispiel <informant typeCode="INF">   <relatedEntity>     <id nullFlavor="UNK"/>    <relatedPerson>       <name>         <given>Hanna</given>        <family>Anverwandt</family>      </name>    </relatedPerson>  </relatedEntity></informant>
Item DT Kard Konf Beschreibung Label hl7:informant (CDA...ant) @typeCode 0 … 1 F INF @context​Control​Code 0 … 1 F OP Auswahl 1 … 1 Elemente in der Auswahl: hl7:assignedEntity[hl7:assigned​Person] hl7:relatedEntity hl7:assignedEntity 0 … 1 Gesundheitsdienstleister (CDA...ant) Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC) hl7:id II 1 … * R (CDA...ant) hl7:addr AD 0 … 1 R (CDA...ant) hl7:telecom TEL 0 … * R (CDA...ant) hl7:assigned​Person 1 … 1 M (CDA...ant) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (CDA...ant) hl7:represented​Organization 0 … 1 (CDA...ant) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (CDA...ant) hl7:name ON 1 … 1 M (CDA...ant) hl7:telecom TEL 0 … * (CDA...ant) hl7:addr AD 0 … 1 (CDA...ant) hl7:relatedEntity 0 … 1 Verwandte, Bekannte, Sozialhelfer, Betreuer/Erzieher (CDA...ant) Eingefügt von 1.2.276.0.76.10.90020 RelatedEntity (Body) (DYNAMIC) @classCode cs 1 … 1 R   CONF Der Wert von @classCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19316 RoleClassMutualRelationship (DYNAMIC) hl7:code CE 0 … 1 (CDA...ant)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19563 PersonalRelationshipRoleType (DYNAMIC) hl7:addr AD 0 … * (CDA...ant) hl7:telecom TEL 0 … * (CDA...ant) hl7:effectiveTime IVL_TS 0 … 1 (CDA...ant) hl7:relatedPerson 0 … 1 (CDA...ant) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (CDA...ant)

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 .

Participant: Empfänger (informationRecipient)

Id	1.2.276.0.76.10.2005	Gültigkeit	2013‑07‑10
Status	Aktiv	Versions-Label
Name	Header​Information​Recipient	Bezeichnung	CDA informationRecipient
Beschreibung Die beabsichtigten Empfänger des Dokuments können in der Klasse IntendedRecipient näher angegeben werden. Hierbei ist zu beachten, dass es sich um die unmittelbar bei der Erstellung des Dokuments festgelegten bzw. bekannten Empfänger handelt. (Es sind nicht die möglichen Empfänger, die jemals eine Kopie des Dokuments empfangen könnten.) So weiß man beispielsweise bei der Erstellung der Dokumentation, dass man einen „Brief" primär an den Hausarzt (informationRecipient.typeCode gleich PRCP, siehe unten) und ggf. einen zweiten („in Kopie") an einen mitbehandelnden Kollegen sendet (informationRecipient.typeCode ist gleich TRC).
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
Beispiel	Beispiel <informationRecipient typeCode="PRCP">   <intendedRecipient>     <id extension="4736437" root="2.16.840.1.113883.3.933"/>    <informationRecipient>       <name>         <prefix>Dr.med.</prefix>        <given>Kai</given>        <family>Heitmann</family>      </name>    </informationRecipient>    <receivedOrganization>       <telecom use="WP" value="fax:+49247365746"/>      <addr>         <streetAddress>Mühlenweg 1a</streetAddress>        <houseNumber>1a</houseNumber>        <postalCode>52152</postalCode>        <city>Simmerath</city>      </addr>    </receivedOrganization>  </intendedRecipient></informationRecipient>
Item DT Kard Konf Beschreibung Label hl7:information​Recipient 0 … * (Hea...ent) @typeCode cs 0 … 1   Typ des Empfängers: im @typeCode der Participation kann angegeben werden, ob es sich um einen primären Empfänger handelt (default) oder einen sekundären Empfänger („CC Kopie"). Der typeCode PRCP ist der default.   CONF @typeCode muss "PRCP" sein oder @typeCode muss "TRC" sein hl7:intended​Recipient 1 … 1 M (Hea...ent) hl7:id II 1 … * R (Hea...ent) Auswahl 1 … * Wenn der beabsichtigte Empfänger eine Person ist, dann wird dies durch die Anwesenheit der Person Klasse mit oder ohne zugehörige Organisation spezifiziert. Wenn der beabsichtigte Empfänger eine Organisation ist, wird nur die Organisation angegeben, die Person fehlt. Elemente in der Auswahl: hl7:information​Recipient hl7:received​Organization hl7:information​Recipient 0 … 1 (Hea...ent) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...ent) hl7:received​Organization 0 … 1 (Hea...ent) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ent) hl7:name ON 1 … 1 M (Hea...ent) hl7:telecom TEL 0 … * (Hea...ent) hl7:addr AD 0 … 1 (Hea...ent)

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 .

Participant: Datentypist (dataEnterer)

Id	1.2.276.0.76.10.2017	Gültigkeit	2014‑08‑25
Status	Entwurf	Versions-Label
Name	HeaderDataEnterer	Bezeichnung	CDA dataEnterer
Beschreibung	Datentypist, die bei der Dateneingabe beteiligte Person(en) wie die Sekretärin u.a.
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.90012 Inklusion CDA Assigned Entity Elements DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.103 CDA dataEnterer (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:dataEnterer 0 … 1 (Hea...rer) @typeCode 0 … 1 F ENT @context​Control​Code 0 … 1 F OP hl7:time TS 0 … 1 gibt den Zeitpunkt an, an dem der Datentypist seinen Beitrag am Dokument beendet hat (Hea...rer) hl7:assignedEntity 1 … 1 R (Hea...rer) Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC) hl7:id II 1 … * R (Hea...rer) hl7:addr AD 0 … 1 R (Hea...rer) hl7:telecom TEL 0 … * R (Hea...rer) hl7:assigned​Person 1 … 1 M (Hea...rer) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...rer) hl7:represented​Organization 0 … 1 (Hea...rer) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...rer) hl7:name ON 1 … 1 M (Hea...rer) hl7:telecom TEL 0 … * (Hea...rer) hl7:addr AD 0 … 1 (Hea...rer)

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

Autor (author - generisch)

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

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 .

Unterzeichner gesetzlich verantwortlich (legalAuthenticator - generisch)

Id	1.2.276.0.76.10.2020	Gültigkeit	2014‑08‑25
Status	Entwurf	Versions-Label
Name	HeaderLegalAuthenticator	Bezeichnung	CDA legalAuthenticator
Beschreibung	Vor dem Gesetz verantwortliche Unterzeichner des Dokumentes
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.90012 Inklusion CDA Assigned Entity Elements DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.106 CDA legalAuthenticator (2005‑09‑07) ref ad1bbr-
Beispiel	Beispiel <legalAuthenticator typeCode="LA">   <time value="20130327130000"/>  <signatureCode code="S"/>  <assignedEntity>     <id extension="a00123456" root="1.2.276.0.76.3.9.8.7.6"/>    <assignedPerson>       <name>         <prefix qualifier="AC">Prof. Dr.</prefix>        <given>Hugo</given>        <family>Reinhardt</family>      </name>    </assignedPerson>    <representedOrganization>       <name>Klinik am Zempiner Steig</name>      <telecom use="WP" value="tel:0332-4556"/>      <telecom use="WP" value="fax:0332-45577"/>      <addr>         <streetName>Zempiner Steig</streetName>        <houseNumber>4</houseNumber>        <postalCode>15266</postalCode>        <city>Berlin</city>      </addr>    </representedOrganization>  </assignedEntity></legalAuthenticator>
Item DT Kard Konf Beschreibung Label hl7:legalAuthenticator 0 … 1 (Hea...tor) @typeCode 0 … 1 F LA @context​Control​Code 0 … 1 F OP hl7:time TS 1 … 1 R (Hea...tor) hl7:signatureCode CS 1 … 1 R (Hea...tor)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC) hl7:assignedEntity 1 … 1 R (Hea...tor) Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC) hl7:id II 1 … * R (Hea...tor) hl7:addr AD 0 … 1 R (Hea...tor) hl7:telecom TEL 0 … * R (Hea...tor) hl7:assigned​Person 1 … 1 M (Hea...tor) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...tor) hl7:represented​Organization 0 … 1 (Hea...tor) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...tor) hl7:name ON 1 … 1 M (Hea...tor) hl7:telecom TEL 0 … * (Hea...tor) hl7:addr AD 0 … 1 (Hea...tor)

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 .

Unterzeichner (authenticator - generisch)

Id	1.2.276.0.76.10.2019	Gültigkeit	2014‑08‑25
Status	Aktiv	Versions-Label
Name	HeaderAuthenticator	Bezeichnung	CDA authenticator
Beschreibung	Unterzeichner des Dokumentes (weitere neben dem vor dem Gesetz verantwortlichen Unterzeichner)
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.90012 Inklusion CDA Assigned Entity Elements DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.107 CDA authenticator (2005‑09‑07) ref ad1bbr-
Beispiel	Beispiel <authenticator typeCode="AUTHEN">   <time value="20130327130000"/>  <signatureCode code="S"/>  <assignedEntity>     <id extension="a00123456" root="1.2.276.0.76.3.1.244.2"/>    <assignedPerson>       <name>         <prefix qualifier="AC">Prof. Dr.</prefix>        <given>Hugo</given>        <family>Reinhardt</family>      </name>    </assignedPerson>    <representedOrganization>       <name>Oberlinklinik</name>      <telecom use="WP" value="tel:0332-4556"/>      <telecom use="WP" value="fax:0332-45577"/>      <addr>         <streetName>Rudolf-Breitscheid-Straße</streetName>        <houseNumber>24</houseNumber>        <postalCode>14482</postalCode>        <city>Potsdam</city>      </addr>    </representedOrganization>  </assignedEntity></authenticator>
Item DT Kard Konf Beschreibung Label hl7:authenticator 0 … * (Hea...tor) @typeCode cs 0 … 1 F AUTHEN hl7:time TS 1 … 1 R (Hea...tor) hl7:signatureCode CS 1 … 1 R (Hea...tor)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC) hl7:assignedEntity 1 … 1 R (Hea...tor) Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC) hl7:id II 1 … * R (Hea...tor) hl7:addr AD 0 … 1 R (Hea...tor) hl7:telecom TEL 0 … * R (Hea...tor) hl7:assigned​Person 1 … 1 M (Hea...tor) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...tor) hl7:represented​Organization 0 … 1 (Hea...tor) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...tor) hl7:name ON 1 … 1 M (Hea...tor) hl7:telecom TEL 0 … * (Hea...tor) hl7:addr AD 0 … 1 (Hea...tor)

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

Verwaltende Organisation (custodian - generisch)

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

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

Weitere Beteiligte

Id	1.2.276.0.76.10.2024	Gültigkeit	2014‑08‑25
Status	Aktiv	Versions-Label
Name	HeaderParticipant	Bezeichnung	CDA participant Weitere Beteiligte
Beschreibung Weitere Beteiligte: Mit dieser Assoziation und den entsprechenden Klassen können weitere für die Dokumentation wichtige beteiligte Personen oder Organisationen wie Angehörige, Verwandte, Versicherungsträger sowie weitere in Beziehung zum Patienten stehende Parteien genannt werden. Hier können auch Leistungserbringer und andere Personen oder Organisationen geführt werden, die für die weitere Behandlung des Patienten relevant sein können
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.108 CDA participant (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:participant 0 … * (Hea...ant) @typeCode cs 1 … 1 R Typischerweise sind hier nur Codes für @typeCode zu verwenden, die nicht durch eine bereits existierende spezialisierte Participantion ausgedrückt werden wie z. B. author, authenticator etc.; es sind nicht alle Kombinationen von @typeCode, functionCode und associatedEntity/code sinnvoll.   CONF Der Wert von @typeCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10901 ParticipationType (DYNAMIC) @context​Control​Code 1 … 1 F OP hl7:functionCode CE 0 … 1 (Hea...ant)   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 IVL_TS 0 … 1 (Hea...ant) hl7:associated​Entity 1 … 1 R (Hea...ant) @classCode cs 1 … 1 R   CONF Der Wert von @classCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19313 RoleClassAssociative (DYNAMIC) hl7:id II 0 … * (Hea...ant) hl7:code CE 0 … 1 (Hea...ant) @codeSystem CONF 0 … 1 F 2.16.840.1.113883.5.111 (RoleCode) hl7:addr AD 0 … * (Hea...ant) hl7:telecom TEL 0 … * (Hea...ant) hl7:associated​Person 0 … 1 (Hea...ant) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...ant) hl7:scoping​Organization 0 … 1 (Hea...ant) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ant) hl7:name ON 1 … 1 M (Hea...ant) hl7:telecom TEL 0 … * (Hea...ant) hl7:addr AD 0 … 1 (Hea...ant)

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 .

Patientenkontakt (EncompassingEncounter - generisch)

Id	1.2.276.0.76.10.2027	Gültigkeit	2014‑08‑25
Status	In Revision	Versions-Label	1.1
Name	Header​Encompassing​Encounter	Bezeichnung	CDA encompassingEncounter Patientenkontakt
Beschreibung Diese Klasse repräsentiert Informationen, in welchem Rahmen der Patientenkontakt, der dokumentiert wird, stattgefunden hat. Dokumente werden nicht notwendigerweise immer während eines Patientenkontakts erstellt, sondern ggf. auch zu einem späteren Zeitpunkt, wenn beispielsweise ein Arzt wegen eines pathologischen Laborwertes den Patienten vergeblich versucht zu erreichen und dennoch seine Verlaufsdokumentation fortführt. Wenn die Dokumentation ein Entlass- oder Verlegungsdokument ist, sollte die Information in dieser Klasse inklusive der Dauer des Aufenthalts und der Einrichtung, wo der Patientenaufenthalt stattfand mitgegeben werden. Dies gilt nicht nur stationäre Aufenthalte, sondern in gegebenem Kontext in übertragenem Sinn auch für einen beendeten Patientenkontakt in der Praxis eines Niedergelassenen.
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.90012 Inklusion CDA Assigned Entity Elements DYNAMIC 1.2.276.0.76.10.90021 Inklusion Encounter Location DYNAMIC
Beispiel	Beispiel <componentOf>   <encompassingEncounter>     <!-- Aufenthalts-Identifikation -->     <id root="1.2.276.0.76.3.87686" extension="657827456837"/>    <!-- Codierung des Patientenkontakts -->     <code code="IMP" displayName="Inpatient encounter" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode"/>    <!-- Zeitraum des Patientenkontakts -->     <effectiveTime>       <low value="20081224082015"/>      <high value="20081225113000"/>    </effectiveTime>    <!-- Verantwortliche Person für den Patientenkontakt -->     <responsibleParty>       <assignedEntity>         <!-- ... -->       </assignedEntity>    </responsibleParty>    <!-- Organisation, in deren Verantwortungsbereich der Patientenkontakt stattfand -->     <location>       <healthCareFacility>         <serviceProviderOrganization>           <!-- ... -->         </serviceProviderOrganization>      </healthCareFacility>    </location>  </encompassingEncounter></componentOf>
Item DT Kard Konf Beschreibung Label hl7:componentOf (Hea...ter) @typeCode cs 0 … 1 F COMP hl7:encompassing​Encounter 1 … 1 R (Hea...ter) @classCode cs 0 … 1 F ENC @moodCode cs 0 … 1 F EVN hl7:id II 0 … 1 Identifikationselement zur Aufnahme der Aufenthalts-Identifikation (Hea...ter) hl7:code CE 1 … 1 M (Hea...ter)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.13955 ActEncounterCode (DYNAMIC)   Beispiel <code code="IMP" codeSystem="2.16.840.1.113883.5.4"/> Auswahl 1 … 1 Elemente in der Auswahl: hl7:effectiveTime[hl7:high] hl7:effectiveTime[@value] hl7:effectiveTime IVL_TS  … 1 R Zeitraum (Hea...ter) wo [hl7:high]   Beispiel Vom 7. Juni 2011 11:24 Uhr bis zum 11. Juni 2011 16:54 Uhr <effectiveTime>   <low value="201106071124"/>  <high value="201106111654"/></effectiveTime> hl7:effectiveTime TS  … 1 R Bestimmter Tag (Hea...ter) wo [@value] @value 1 … 1 R   Beispiel Am 7. Juni 2011 (ambulanter Besuch ohne genauere Zeitangaben des Tages) <effectiveTime value="20110607"/> hl7:responsible​Party 0 … 1 (Hea...ter) hl7:assignedEntity 1 … 1 M (Hea...ter) Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC) hl7:id II 1 … * R (Hea...ter) hl7:addr AD 0 … 1 R (Hea...ter) hl7:telecom TEL 0 … * R (Hea...ter) hl7:assigned​Person 1 … 1 M (Hea...ter) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...ter) hl7:represented​Organization 0 … 1 (Hea...ter) Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...ter) hl7:name ON 1 … 1 M (Hea...ter) hl7:telecom TEL 0 … * (Hea...ter) hl7:addr AD 0 … 1 (Hea...ter) Eingefügt 0 … 1 R von 1.2.276.0.76.10.90021 Encounter Location (DYNAMIC) hl7:location 0 … 1 R (Hea...ter) @typeCode 0 … 1 F LOC   Beispiel <location typeCode="LOC">   <healthCareFacility classCode="SDLOC">     <!-- ... -->   </healthCareFacility></location> hl7:health​Care​Facility 1 … 1 M (Hea...ter) @classCode 0 … 1 F SDLOC   Beispiel <healthCareFacility classCode="SDLOC">   <serviceProviderOrganization classCode="ORG" determinerCode="INSTANCE">     <!-- ... -->   </serviceProviderOrganization></healthCareFacility> hl7:service​Provider​Organization 1 … 1 M (Hea...ter) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE   Beispiel <serviceProviderOrganization classCode="ORG" determinerCode="INSTANCE">   <name/>  <addr>     <!-- ... -->   </addr></serviceProviderOrganization> hl7:id II 1 … * R (Hea...ter) hl7:name ON 1 … 1 M (Hea...ter) hl7:telecom TEL 1 … * M (Hea...ter) hl7:addr AD 1 … 1 M (Hea...ter)

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

Section: Anrede

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

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: Grund der Überweisung

Id	1.2.276.0.76.10.3002	Gültigkeit	2013‑09‑16 Andere Versionen mit dieser Id: ReasonForReferral vom 2017‑02‑01 ReasonForReferral vom 2013‑01‑10
Status	Aktiv	Versions-Label
Name	ReasonForReferral	Bezeichnung	Grund der Überweisung Section
Beschreibung Dieser Abschnitt enthält die konkrete (medizinische) Fragestellung bzw. Grund für eine Überweisung, die sich aufgrund einer medizinischen Untersuchung ergibt, formuliert als Freitext und in einer eigenen Komponente abgelegt.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3002
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Adaptation: Template 1.3.6.1.4.1.19376.1.5.3.1.3.1 IHE Reason for Referral Section (DYNAMIC) ref IHE-PCC- Adaptation: Template 1.2.40.0.34.11.2.2.1 Aufnahmegrund (DYNAMIC) ref elgabbr- Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr-
Beispiel	Beispiel <section>   <code code="42349-1" codeSystem="2.16.840.1.113883.6.1"/>  <title>Grund der Überweisung</title>  <text>Röntgen Thorax in zwei Ebenen</text></section>
Item DT Kard Konf Beschreibung Label hl7:section (Rea...ral) hl7:templateId II 1 … 1 (Rea...ral) @root 1 … 1 F 1.2.276.0.76.10.3002 hl7:code CE 1 … 1 M (Rea...ral) @code CONF 1 … 1 F 42349-1 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC)   Beispiel <code code="42349-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> hl7:title 1 … 1 M (Rea...ral)   CONF Elementinhalt muss "Grund der Überweisung" sein hl7:text SD.TEXT 1 … 1 M Hier wird die eigentliche Fragestellung platziert. (Rea...ral)

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

In diesem Leitfaden werden die folgenden Anamnese-Informationen unterstützt.

Jetzige Anamnese

Id	1.2.276.0.76.10.3022	Gültigkeit	2013‑12‑30
Status	Aktiv	Versions-Label
Name	Historyofpresentillnesssection	Bezeichnung	Jetzige Anamnese
Beschreibung	Jetzige Anamnese
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 (His...ion) hl7:templateId II 1 … 1 (His...ion) @root 1 … 1 F 1.2.276.0.76.10.3022 hl7:code CE 1 … 1 M (His...ion) @code CONF 1 … 1 F 10164-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (His...ion)   CONF Elementinhalt muss "Jetzige Anamnese" sein hl7:text SD.TEXT 1 … 1 M (His...ion)

Frühere Erkrankungen

Id	1.2.276.0.76.10.3023	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Historyofpastillnesssection vom 2017‑04‑09
Status	Aktiv	Versions-Label
Name	Historyofpastillnesssection	Bezeichnung	Frühere Erkrankungen
Beschreibung	Liste der bisherigen Krankheiten 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 (His...ion) hl7:templateId II 1 … 1 (His...ion) @root 1 … 1 F 1.2.276.0.76.10.3023 hl7:code CE 1 … 1 M (His...ion) @code CONF 1 … 1 F 11348-0 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (His...ion)   CONF Elementinhalt muss "Frühere Erkrankungen" sein hl7:text SD.TEXT 1 … 1 M (His...ion)

Familienanamnese

Id	1.2.276.0.76.10.3024	Gültigkeit	2013‑12‑30
Status	Aktiv	Versions-Label
Name	Familyhistorysection	Bezeichnung	Familienanamnese
Beschreibung	Angaben über Erkrankungen macht, die bei Verwandten des Patienten aufgetreten sind.
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 (Fam...ion) hl7:templateId II 1 … 1 (Fam...ion) @root 1 … 1 F 1.2.276.0.76.10.3024 hl7:code CE 1 … 1 M (Fam...ion) @code CONF 1 … 1 F 10157-6 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Fam...ion)   CONF Elementinhalt muss "Familienanamnese" sein hl7:text SD.TEXT 1 … 1 M (Fam...ion)

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: Erhobene Befunde

Id	1.2.276.0.76.10.3025	Gültigkeit	2013‑12‑30
Status	Aktiv	Versions-Label
Name	Hospital​discharge​studies​summary​section	Bezeichnung	Erhobene Befunde (Krankenhaus)
Beschreibung	Im Krankenhaus erhobene Befunde
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	Beispiel <section>   <templateId root="1.2.276.0.76.10.3025"/>  <code code="11493-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Erhobene Befunde (Krankenhaus)</title>  <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></section>
Item DT Kard Konf Beschreibung Label hl7:section (Hos...ion) hl7:templateId II 1 … 1 (Hos...ion) @root 1 … 1 F 1.2.276.0.76.10.3025 hl7:code CE 1 … 1 M (Hos...ion) @code CONF 1 … 1 F 11493-4 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Hos...ion)   CONF Elementinhalt muss "Erhobene Befunde" sein -oder- Elementinhalt muss "Erhobene Befunde (Krankenhaus)" sein hl7:text SD.TEXT 1 … 1 M (Hos...ion)

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 .

Entry: ICD-Diagnose (allgemein)

	Template-Metadaten
Template-Typ	Entry
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
Generelle Beschreibung	Hiermit wird auf Entry-Level die Übermittlung von Diagnosedaten definiert.
allg. Erläuterung	IG:Diagnoseleitfaden
Verhältnis zu IHE	neu
Ballotierungsstatus	in Arbeit
Erweiterbarkeit	geschlossen

Einleitung: ICD-10 GM codierte Diagnosen

Die „International Statistical Classification of Diseases" (ICD) ist ein Klassifizierungssystem für Krankheiten und verwandter Gesundheitsprobleme. Sie ist hierarchisch gegliedert. Die ICD-10-GM ist als deutsche Abwandlung (German Modification) eine länderspezifische Variante der ICD-10 der WHO. Die Krankheiten werden über alphanumerische Codes klassifiziert. Jede Krankheit ist einem Code eindeutig zugeordnet. Bei den Codes handelt es sich überwiegend um so genannte Primärdiagnoseschlüssel, die alle Informationen zur Verschlüsselung der jeweiligen Krankheit beinhalten. Zusätzlich liegen in der ICD-10 Sekundärdiagnoseschlüssel vor, die ergänzende Informationen enthalten. Sekundärdiagnoseschlüssel sind in der Klassifikation selbst eindeutig mit einem Stern (*) oder Ausrufezeichen (!) als Zusatzkennzeichen des Codes gekennzeichnet. Sie sind nur in Verbindung mit einer Primärdiagnose zu verwenden. Primärdiagnosecodes führen kein Kennzeichen oder ein Kreuz (+). Beispiel.: E14.30+, H28.0* ICD-10 Code für "Diabetes mellitus mit Katarakt"

ICD-10 Code Begrifflichkeiten

Zur Verschlüsslung von Diagnosen in der ambulanten und stationären Versorgung wird seit dem 01.01.2004 die ICD-10-GM verwendet. Bei der Codierung der Diagnosen müssen im stationären Bereich (§ 301) die Deutschen Codierrichtlinien beachtet werden und die durch das BMG genehmigte Codeerweiterungen. Auf diese und die Codeerweiterungen wird im folgendem eingegangen. Für den ambulanten Bereich gilt die WHO-Tabelle mit BMG-Ergänzungen.

Kreuz–Stern Diagnosen, Ausrufezeichen (!)

Bei der ICD-10 GM wird zwischen Primär- und Sekundärcodes unterschieden. Primärcodes sind Codes ohne Kennzeichen und Codes mit einem Kreuz. Sekundärcodes sind Codes mit einem Stern oder einem Ausrufzeichen. Um die Begrifflichkeiten näher zu beschreiben, werden hier einige Zitate aus der Broschüre „Basiswissen Kodieren" (DIMDI, Basis) aufgeführt. „ .. Der Code für die Ätiologie einer Erkrankung wird in der ICD-Codierung mit einem Kreuz (†) gekennzeichnet und die Organmanifestation mit einem Stern (*). Hierbei darf der Stern-Code aber nie alleine verwendet werden. Der Kreuz-Code ist der Primärcode." Weiterhin gilt: „ ... Als Sterncodes darf man nur diejenigen Codes verwenden, die in der ICD-10-GM explizit als solche definiert sind..." „... Zulässig ist es hingegen, den Code für eine Grunderkrankung mit einem Kreuz zu ergänzen, wenn für die Krankheitsmanifestation ein passender Sterncode zur Verfügung steht..." „... Manche Codes sind mit einem Ausrufezeichen (!) gekennzeichnet. Hierbei handelt es sich um Zusatzcodes, die eine Krankheit näher beschreiben oder deren Schweregrad abgrenzen. Diese Codes dürfen ebenfalls nicht alleine stehen..."

Daraus folgt, dass eine Diagnose mindestens durch einen Primärcode beschrieben wird und falls notwendig, durch die zusätzliche Angabe von Sekundärcodes. Der Primär- bzw. der Sekundärcode selbst setzt sich zusammen aus einer alphanumerischen Zeichenkette, welche den Code repräsentiert und einen Code-Zusatzkennzeichen (†, *, !).

Seitenlokalisation

Zur Angabe der Seitenlokalisation wird hier ein Abschnitt aus der „ICD-10-Bekanntmachung des BMGS" vom 21.10.2004 zitiert. „.. Für die Anwendung des ICD-10-GM gilt Folgendes: Zur Spezifizierung der Diagnoseangaben für die Seitenlokalisation darf eines der nachgenannten Zusatzkennzeichen angegeben werden: – rechts: R – links: L – beidseitig: B ..." (BMGS, 2004) Daraus ergibt sich, dass es möglich sein muss, zu jedem ICD-10 Code eine Seitenlokalisation anzugeben. Anmerkung: Die Seitenlokalisation kann für den Primärcode ein anderer sein als für den Sekundärcode.

Beispiel:
C50.4 R Mamma Ca - rechts
J91* L Pleuraerguss bei sonstiger Erkrankung - links

In der Tumordokumentation gilt die erweiterte Tabelle. Anmerkung: In manchen Fällen ist die Benutzung des Begriffs „beidseits" notwendig.

Diagnosesicherheit

„... Für die Anwendung der ICD-10-GM nach § 295 SGB V (ambulanter Bereich) gilt zusätzlich Folgendes: Zur Angabe der Diagnosesicherheit ist eines der nachgenannten Zusatzkennzeichen anzugeben (obligatorische Anwendung – für eine ausgeschlossene Diagnose: A – für eine Verdachtsdiagnose: V – für einen symptomlosen Zustand nach der betreffenden Diagnose: Z – für eine gesicherte Diagnose: G..." (BMGS, 2004) Das heißt, wird eine Diagnose im Rahmen einer „Abrechnung ärztlicher Leistungen" (§295 SGB V) angegeben, ist neben der Angabe des ICD-10 Codes, die Angabe der Diagnosesicherheit zwingend erforderlich. Im stationären Bereich dürfen diese Angaben nicht verwendet werden. (siehe Änderung zu 3.9)

Darstellung des Diagnosemodells in HL7 V3

Die Diagnose wird in HL7 V3 über die Klasse Observation dargestellt. Die Klasse ist, wie in Abbildung 1: Klasse Observation gezeigt aufgebaut.

Abbildung 1: Klasse Observation

Auf die genauere Beschreibung der einzelnen Klassen und die verwendeten Datentypen wird hier verzichtet. Nähere Informationen dazu sind der HL7 V3-Dokumentation oder dem Datentypen-Leitfaden (HL7 Datentypen) zu entnehmen.

Attribute

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Elemente der beschriebenen Diagnosemerkmale, über die Klasse Observation dargestellt werden.

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Observation		0..*		Diagnose
2	act	@moodCode		0..1	F	Das Attribut @moodCode beschreibt, wie der Inhalt einer Act-Klasse zu interpretieren ist. Für die Klasse Observation, die eine Diagnose beschreibt, hat das Attribut den festen Wert EVN. Damit wird ausgedrückt, dass es sich um eine Dokumentation eines vorangegangenen Ereignisses handelt, also um die Dokumentation des Ergebnisses einer Beobachtung. "EVN"
2	act	@classCode		0..1	F	Das Attribut @classCode spezifiziert den Haupttyp des Akts, der über eine Instanz repräsentiert wird. Über eine Klasse Observation wird immer eine Observation (Beobachtung) dargestellt. Somit hat das Attribut @classCode den festen Wert OBS. In der XML-Struktur wird das Attribut als XML-Attribut des Elements Observation dargestellt. Die Angabe des Attributs in der XML-Strukur ist optional. Wird es nicht angegeben, geht das empfangende System von dem festen Wert aus und verwendet diesen zur weiteren Verarbeitung. "OBS"
2	act	id	SET <II>	0..1	O	Identifikation Über das Attribut id kann die Diagnose eine eindeutige Identifikation innerhalb eines Systems erhalten. Für die Verarbeitung von Diagnosedaten über ein rechnergestütztes System ist die Vergabe von Ids empfehlenswert, um gezielt auf den Datensatz der Diagnose zugreifen zu können. In der XML-Repräsentation wird die Diagnose-ID im Attribut @extension und die OID des Systems im Attribut @root angegeben. Sollen für Diagnosen später Änderungen oder Löschungen kommuniziert werden, ist eine eindeutige Referenzierung über diese Identifikation unerlässlich.
2	act	code	CD CWE	1..1	R	Diagnosetyp Im XML-Attribut @code wird der Klassifizierungscode angegeben im Attribut @codeSystem die OID des Codierungssystems (siehe auch Anhang 10).
3	act	@code		1..1	R
3	act	@codeSystem		1..1	R
2	act	negationInd	BL	0..1	O	Negation Das Attribut @negationInd ist vom Datentyp BL und hat damit die Ausprägungen "true" oder "false". Wird das Attribut mit „true" angegeben, so wird ausgesagt, dass die über die Observation-Klasse beschriebene Beobachtung negiert wird. In Bezug auf die Diagnosendarstellung bedeutet das, dass die beschriebene Diagnose nicht zutrifft. Die Angabe des Attributs ist optional. Wird es nicht angegeben, geht das empfangende System von dem Default-Wert aus und verwendet diesen zur weiteren Verarbeitung. Der Default–Wert ist „false".
2	act	statusCode		1..1	F	Status Über dieses Attribut wird der Status, in dem der beschriebene Act sich befindet, angegeben. Ein Act kann z.B. den Status „new", „active" oder „cancelled" besitzen. Die Beobachtung einer Diagnose wird mit der Dokumentation als abgeschlossene Handlung betrachtet. Somit wird für das Attribut statusCode der feste Wert „completed" vorgegeben.
2	act	text	ST	0..1	O	Diagnoseerläuterung Der erläuternde Text zu einer Diagnose wird über das Attribut @text abgebildet. Die strukturierte Darstellung sieht wie folgt aus.
2	act	effectiveTime	IVL<TS>	0..1		Diagnosezeitraum Das Attribute effectiveTime der Klasse Observation gibt den Zeitraum an, für den die beschriebene Beobachtung für den Patienten gültig (klinisch relevant) ist bzw. war. In Bezug auf die Darstellung einer Diagnose, handelt es sich um den Diagnosezeitraum, der über das Element effectiveTime abgebildet wird. Über das Unterelement low wird das Startdatum des Zeitraums angegeben, über das Unterelement high das Enddatum. Sowohl das Element low als auch das Element high können alleine angegeben werden.
2	act	value	CD	0..1	O	Diagnosecode und Text Die Darstellung eines Diagnosecodes und des zum Code gehörenden Text erfolgt über das Attribut value der Klasse Observation. Das XML-Attribut @code des Elements value enthält den Diagnosecode, das XML-Attribut @displayName enthält den zum Code gehörenden Text. Die strukturierte Darstellung für eine ICD-10 codierte Diagnose sieht wie folgt aus.
3	act	@code		1..1	M	Diagnosecode
3	act	@codeSystem		1..1	M	Codesystem für den Diagnosecode Im XML-Attribut @codeSystem ist die OID für den ICD-10-GM in der jeweils gültigen Version angegeben.
3	act	@codeSystemName		0..1	O	Name des Codesystem für den Diagnosecode Die Angabe des XML-Attributes @codeSystemName enthält den offiziellen Namen des Codiersystems.
3	act	orginalText	ST	0..1	O	Freitext Die Darstellung der Freitextbezeichnung der Diagnose erfolgt über das Element value und dessen Unterelement orginalText. Über das Element orginalText wird die wörtliche Bezeichnung der konkreten Diagnose angegeben, die im Element value codiert dargestellt wird. Ist die Angabe eines Diagnosekodes nicht erforderlich oder ist dieser unbekannt, so ist im Element value das Attribut @nullFlavour mit aufzuführen. Mit diesem Attribut wird das Fehlen der Codierung begründet. Der Wert „NAV" (temporarily unavailable) sagt aus, dass (noch) keine Code-Informationen vorliegen. Weitere mögliche Werte sind der HL7-Dokumentation zu entnehmen.
4	act	@language		0..1	O	Sprache Über das Attribut @language des Element orginalText kann die Sprache des Textinhalts definiert werden.
2	act	value		0..1	O	Diagnosesicherheit
3	act	qualifier	CR	0..1	O	Diagnosesicherheit Die Angabe der Diagnosesicherheit wird über ein Kindelement qualifier des Elements value abgebildet.
4	act	name		1..1	R	Über das Attribut @code im Element name wird die Bezeichnung für den Qualifier angegeben. Die Diagnosesicherheit wird aus der unten gezeigten Tabelle entnommen. Im Attribut @codeSystem wird die OID der Systems angegeben, welches den Qualifiernamen beinhaltet (s. u.). Die Angabe zur Diagnosesicherheit selbst wird im Attribut @code des Elements value abgebildet. In der ambulanten Versorgung (§ 295 SGB V) sind die Zusatzkennzeichen für die Diagnosensicherheit obligatorisch. In der stationären Versorgung (§ 301 SGB V) sind die Zusatzkennzeichen für die Diagnosensicherheit verboten, d.h. sie dürfen nicht verwendet werden.
5	act	@code		1..1	R
5	act	@codeSystem		1..1	R
4	act	value		1..1
5	act	@code		1..1
5	act	@codeSystem		1..1
2	act	targetSiteCode	CD CWE	0..1	O	Lokalisation Die Lokalisation zu Diagnosen wird über das Element targetSiteCode angegeben. Wird die Lokalisation im Freitext angegeben, erfolgt die Darstellung über das Unterelement orginalText. Bei fehlender Codierung muss im Element targetSiteCode das Attribut @nullFlavor angegeben werden.
2	act	author		0..1	O	Das Diagnosedatum wird über die Klasse author dargestellt, welche als Participation mit der Klasse Observation verbunden ist.
3	act	@time	IVL<TS>	0..1	O	Diagnosedatum Das Diagnosedatum gibt an, wann die Krankheit diagnostiziert wurde. Das Diagnosedatum muss nicht gleich dem Dokumentationsdatum sein. Die Klasse author enthält ein Attribut time vom Datentyp IVL <TS>. Nähere Informationen zu der Person, welche die Krankheit diagnostiziert hat, können über die Klasse assignedEntity abgebildet werden.
2	act	participant		1..1		DataEnterer
3	act	@time	TS	1..1	R	Dokumentationsdatum Das Dokumentationsdatum ist das Datum, an dem die Krankheit z.B. durch einen Arzt dokumentiert wurde. Diese Datumsangabe wird über die Klasse dataEnterer abgebildet, welche als Participation mit der Klasse Observation verknüpft ist (vgl. Abbildung 1: Klasse Observation). Die Klasse dataEnterer enthält ein Attribut time vom Datentyp TS. D.h., dass in der XML-Struktur die Datumsangabe über einem Element time und dessen Attribute @value abgebildet wird. Ist keine explizite Klasse dataEnterer vorhanden, so wird eine Participation-Klasse durch die Angabe des Attributes typeCode mit dem Wert ENT zu einer Klasse dataEnterer. Über die Klasse paticipationRole kann die Person näher beschrieben werden.
2	act	entryRelationship		0..1	O	Begründung von Ausnahmen
3	act	@typeCode		1..1	O	Das Attribute @typeCode erhält den Wert RSON (= reason), da es sich um eine Begründung zu Abrechnungszwecken handelt.
3	act	observation		0..1	O	moodCode="EVN", classCode="OBS"
4	act	code		0..1	O	nullFlavor="UNK"
4	act	value	ST	0..1	O	Ausnahmebegründung Die Begründung der abrechnungsrelevanten Ausnahme wird in dem Attribut @value einer Klasse Observation dargestellt, welche über eine ActRelationship-Klasse mit der diagnosebeschreibenden Klasse Observation verlinkt ist.

Beispiel

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
	...
	<code code="DX" codeSystem="1.2.276.0.76.5.342"/>

	<statusCode code="completed"/>
	<!-- Diagnosezeitraum -->
	<effectiveTime>
		<low value="20050127"/>
	</effectiveTime>
	<!-- ICD-Code einer Diagnose -->
	<value xsi:type="CD" code="I01.0" 
		displayName="Akute rheumatische Perikarditis"
		codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006">
		<originalText>......</originalText>
		<!--Diagnosesicherheit-->
		<qualifier>
			<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
		</qualifier>
	</value>
	<text>Intermittierend, seit der Jugend</text>
	<targetSiteCode nullFlavor="NI">
		<originalText>Oberhalb des rechten Knöchels</originalText>
	</targetSiteCode>
	...
	<!-- Dokumentationsdatum -->
	<participant typeCode="ENT">
		<time value="20060606"/>
		<participantRole>
		...
		</participantRole>
	</participant>
	...
	<author>
	<!-- Diagnosedatum -->
		<time value="20060613"/>
		<assignedAuthor>
			...
		</assignedAuthor>
	</author>
	...
	<!-- Ausnahmetatbestand-->
	<entryRelationship typeCode="RSON">
		<observation moodCode="EVN" classCode="OBS">
			<code nullFlavor="UNK"/>
			<value xsi:type="ED">...........</value>
		</observation>
	</entryRelationship>
	...
</observation>

Vokabularien

Sicherheit der Diagnose

Code lt. §295 SGB V	Umsetzung	Bedeutung	Erläuterung
G		Gesichert	Gesicherte Diagnose
V	uncertaintyCode = UN	Verdacht auf	Verdachtsdiagnose
Z		Zustand nach	Zustand nach
A	negationInd = true	Ausgeschlossene Erkrankung	Ausgeschlossene Erkrankung, gleichzeitig ist dies in Level 3 mittels negationInd anzugeben (siehe auch Hinweis im Text)

Tabelle 2: Vocabulary Domain für Sicherheit/Verlässlichkeit
Codesystem: Sciphox (OID: 2.16.840.1.113883.3.7.1.8)

Sicherung der Diagnose

In der Tumordokumentation wird der Begriff der Sicherung der Diagnose noch durch die Angabe des (höchstwertigen) Diagnoseverfahrens ergänzt. Diese Information wird ebenfalls als Qualifier übermittelt:

Code	Umsetzung	Bedeutung	Erläuterung
k		klinisch
z		zytologisch
h		histologisch
a		autoptisch
d		DCO	Nur auf Leichenschauschein notiert. Death certificate only.
	nullFlavor = OTH	Sonstiges
	nullFlavor = NI	unbekannt

Tabelle 3: Vocabulary Domain für Diagnoseverfahren in der Tumordokumentation
Codesystem: (OID: 1.2.276.0.76.5.418)

Lokalisation der Diagnose

Wird die Lokalisation über einen Code oder Zusatzcode ausgedrückt, so wird der Code im Attribut @code und das verwendete Codiersystem über das Attribut @codeSystem angegeben. Optional kann über das Attribut @displayName der zum Code gehörende Text angegeben werden und über das Attribut @codeSystemName der Name des Codiersystems

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
	...
	<targetSiteCode code="299058009" codeSystem="2.16.840.1.113883.6.96" 
		codeSystemName="SNOMED CT" displayName="kleiner Finger">
		<qualifier>
			<name code="78615007" codeSystem="2.16.840.1.113883.6.96" 
				codeSystemName="SNOMED CT" displayName="mit Seitenlokalisation"/>
			<value code="24028007" codeSystem="2.16.840.1.113883.6.96" 
				codeSystemName="SNOMED CT" displayName="rechts"/>
		</qualifier>
	</targetSiteCode>
	...
</observation>

Anmerkung: Die vom BMG vorgeschlagenen Codes sollten auch nur im Zusammenhang mit ICD-10 codierten Diagnosen verwendet werden. Die Zusatzkennzeichen für die Seitenlokalisation dürfen sowohl in der ambulanten als auch in der stationären Versorgung verwendet werden. In anderen Fällen sollten andere Codierungsschemata Anwendung finden. In der Tumordokumentation werden weitere Codierungen für die Seitenangabe verwendet:

Code	Umsetzung	Bedeutung	Erläuterung	allg.	Tumordok.
R		Rechts	Seitenlokalisation rechts	X	X
L		Links	Seitenlokalisation links	X	X
B		beidseits	beidseitiges Auftreten	X	X
M		Mittellinie	Mittellinienzone (je 2cm rechts oder links d. Mittellinie)		X
	nullFlavor = NA	Systemerkrankung	(bzw. im Sinne von „nicht zutreffend")		X
	nullFlavor = UNK	Unbekannt		X	X

Tabelle 4: Vocabulary Domain für Lokalisation Codesystem: (OID: 1.2.276.0.76.5.412)

Die Seitenlokalisation wird in der allgemeinen Diagnosedokumentation und der Tumordokumentation mit unterschiedlichen Werten eingesetzt. Diese beiden Value Sets sind in den beiden rechten Spalten dargestellt. Nachfolgend die Spezifikation der dazu¬gehörigen Value Sets:

Value Set	Erläuterung	OID
Allgemein nach ICD-10		2.16.840.1.113883.3.7.1.7
Tumordokumentation		1.2.276.0.76.11.10

Tabelle 5: Value Sets für Lokalisation

Beispiele

Freitext

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
  ...
  <value xsi:type="CD" nullFlavor="NAV">
    <originalText>
      Rektumkarzinom mit Höhenlokalisation ab Anokutanlinie/Linea dentata
    </originalText>
  </value>
</observation>

Abbildung einer ICD-10 codierten Diagnose in HL7 V3

Bei der strukturierten Darstellung einer ICD-10 codierten Diagnose muss es möglich sein, zwei ICD-Codes (Primär-, Sekundärcode), mit den beschriebenen Eigenschaften (Codeerweiterung, Seitenlokalisation, Diagnosesicherheit) abbilden zu können. Der Primärcode kennzeichnet dabei die Grunderkrankung. Der Sekundärcode wird als Zusatzangabe zum Primärcode verstanden, da er entweder dazu verwendet wird Organmanifestationen näher zu beschreiben (Stern-Code) und/oder den Auslöser (Ätiologie, z. B. welcher Erreger) einer Krankheit näher zu spezifizieren (Ausrufezeichen).

Um diese Abhängigkeit darzustellen, wird der Sekundärcode über eine weitere Klasse Observation abgebildet, welche über eine ActRelationship–Klasse mit der Klasse Observation referenziert, die den Primärcode beinhaltet. Daraus leitet sich folgende Grundstruktur einer ICD-10 verschlüsselten Diagnose ab.

Abbildung 2: Blockdiagramm ICD-10 Diagnose

Über das Attribut typeCode der ActRelationship-Klasse soll die Codeerweiterung abgebildet werden. Über die Klasse Observation, die über eine ActRelationship-Klasse mit dem typeCode MFST (Manifestation) eingebunden wird, werden Sterncodes dargestellt. Codes mit einem Ausrufezeichen als Codeerweiterung werden in einer Klasse Observation abgebildet, die über eine ActRelationship-Klasse mit dem typeCode CAUS (Ursache) eingebunden werden. Die XML-Struktur einer ICD-10 codierten Diagnose sieht demnach wie folgt aus:

<!-- Strukturierte Darstellung der Diagnose-->
<observation moodCode="EVN" classCode="OBS">
	…
	<!-- Primärcode-->
	<value xsi:type="CD" code=" E14.30" codeSystem=" 1.2.276.0.76.5.311"/>
	<entryRelationship typeCode="MFST">
		<observation moodCode="EVN" classCode="OBS">
			…
			<!-- Sekundärcode-->
			<value xsi:type="CD" code=" H28.0" codeSystem=" 1.2.276.0.76.5.311"/>
		</observation>
	</entryRelationship>
</observation>

In diesem Fall ist die einbindende ActRelationship-Klasse die Klasse entryRelationsship, welche durch das gleichnamige Element repräsentiert wird. Das Attribute @typeCode erhält den festen Wert MFST, womit auf einen Sterncode verwiesen wird.

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	value			1..1	M
2	act	@code	ST	1..1	M	ICD-Code Das XML-Attribut @code enthält den ICD-10 Code.
2	act	@codeSystem	UID	1..1	M	OID der ICD-10 Version Das XML-Attribut @codeSystem enthält die OID der verwendeten ICD Version, mit der auf die ICD-10 GM verwiesen wird. Hinweise zu gültigen Codesystemen sind im Anhang genannt.
2	act	@codeSystemName	ST	0..1	optional	Name der ICD-10 Version Im XML-Attribut @codeSystemName kann der Name der aktuellen ICD-10 Version angeben werden.
2	act	@displayName	ST	0..1	optional	ICD-Code -Text Im XML-Attribute @displayName kann, der zum ICD-Code gehörende Text angegeben werden. Die OID und die Bezeichnung der ICD-10 Version(en) können von der Internetseite des DIMDIs bezogen werden.

Darstellung der Seitenlokalisation

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	value		0..1	O
2	act	qualifier	CR	0..1	O	Seitenlokalisation Die Abbildung des Seitenlokalisationscode erfolgt über ein Kindelement qualifier des Elements value, da er eine nähere Beschreibung des Diagnosecodes ist . Die Darstellung sieht wie folgt aus:

<!-- Strukturierte Darstellung der Diagnose -->
<observation moodCode="EVN" classCode="OBS">
	<code code="DX" codeSystem=""/>
	<!-- Primärcode-->
	<value xsi:type="CD" code="E14.30" codeSystem="1.2.276.0.76.5.311">
		<qualifier>
			<name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/>
		</qualifier>
	</value>
	<entryRelationship typeCode="CAUS">
		<observation moodCode="EVN" classCode="OBS">
			<code/>
			<!-- Sekundärcode-->
			<value xsi:type="CD" code="H28.0" codeSystem="1.2.276.0.76.5.311">
				<qualifier>
					<name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
					<value code="B" codeSystem="2.16.840.1.113883.3.7.1.7"/>
				</qualifier>
			</value>
		</observation>
	</entryRelationship>
</observation>

Über das Kindelement name des Elements qualifier wird die Art des Qualifiers bezeichnet. Um auszudrücken, dass es sich um einen Qualifier zur Seitenlokalisation handelt, muss hier „7" angegeben mit Codesystem OID 2.16.840.1.113883.3.7.1.0 angegeben werden:

<qualifier>
	<name code="7" codeSystem="2.16.840.1.113883.3.7.1.0"/>
	<value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/>
</qualifier>

Darstellung der Diagnosesicherheit

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	value		0..1	O	Diagnosesicherheit
2	act	@qualifier	CR	0..1	O	Diagnosesicherheit Die Angabe der Diagnosesicherheit, welche als „Anhang" zu einem ICD-Code mit angegeben werden kann, wird über ein Kindelement qualifier des Element value abgebildet.

<!-- Strukturierte Darstellung der Diagnose-->
<observation moodCode="EVN" classCode="OBS">
	<code code="" codeSystem=""/>
	<!-- Primärcode-->
	<value xsi:type="CD" code="E14.30" codeSystem="1.2.276.0.76.5.311">
		<qualifier>
			<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
		</qualifier>
	</value>
	<entryRelationship typeCode="CAUS">
		<observation moodCode="EVN" classCode="OBS" negationInd="true">
			<code/>
		<!-- Sekundärcode-->
			<value xsi:type="CD" code="H28.0" codeSystem="1.2.276.0.76.5.311">
				<qualifier>
					<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
					<value code="A" codeSystem="2.16.840.1.113883.3.7.1.8"/>
				</qualifier>
			</value>
		</observation>
	</entryRelationship>
</observation>

Über das Kindelement name des Elements qualifier wird die Art des Qualifiers bezeichnet. Als fixer Wert bei der Angabe der ICD-Code Erweiterung muss hier „8" angegeben werden. Im Kindelement value des Elements qualifier wird der entsprechende Wert angegeben. Die zulässigen Werte sind in Tabelle 2 zusammengefasst.

<observation classCode="OBS" moodCode="EVN">
	...
	<value xsi:type="CD" code="A25.1" codeSystem="1.2.276.0.76.5.311" 
			codeSystemName="icd10gm2006">
		<qualifier>
			<name code="8" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/>
		</qualifier>
	</value>
</observation>

Bei der Angabe einer ausgeschlossenen Diagnose muss das Attribut @negationInd mit dem Wert „true" angegeben werden.

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: Allergien, Unverträglichkeiten, Risiken

In diesem Abschnitt (auch CAVE genannt) werden

• Hinweise zu Risikofaktoren beim Patienten und
• Allergien

abgebildet.

Id	1.2.276.0.76.10.3028	Gültigkeit	2013‑12‑30
Status	Aktiv	Versions-Label
Name	Allergiesintolerancesriskssection	Bezeichnung	Allergien, Unverträglichkeiten, Risiken
Beschreibung	Beschreibung der Allergien, Unverträglichkeiten und Risiken und deren beobachteten Nebenwirkungen, sowie sonstiger Risiken.
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	Beispiel <section>   <templateId root="1.2.276.0.76.10.3028"/>  <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Allergien, Unverträglichkeiten, Risiken</title>  <text>Penicillinallergie</text></section>
Item DT Kard Konf Beschreibung Label hl7:section (All...ion) hl7:templateId II 1 … 1 (All...ion) @root 1 … 1 F 1.2.276.0.76.10.3028 hl7:code CE 1 … 1 M (All...ion) @code CONF 1 … 1 F 48765-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (All...ion)   CONF Elementinhalt muss "Allergien, Unverträglichkeiten, Risiken" sein hl7:text SD.TEXT 1 … 1 M (All...ion)

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: Prozeduren und Maßnahmen

In dem Abschnitt Prozeduren und Maßnahmen werden u. a.

• Fachspezifische Eingriffe
• Operationen
• Strahlentherapie
• Lichttherapie
• Psychiatrische Therapie

abgebildet.

Damit ist die Weitergabe von Freitextprozeduren oder Prozeduren ohne OPS möglich.

Id	1.2.276.0.76.10.3032	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Proceduressection vom 2017‑02‑01
Status	Aktiv	Versions-Label
Name	Proceduressection	Bezeichnung	Prozeduren und Maßnahmen
Beschreibung	Kurzbeschreibung sämtlicher während des Aufenthalts durch-geführten Maßnahmen, wie OPs, Eingriffe oder sonstige Maßnahmen.
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 (Pro...ion) hl7:templateId II 1 … 1 (Pro...ion) @root uid 1 … 1 F 1.2.276.0.76.10.3032 hl7:code CE 1 … 1 M (Pro...ion) @code CONF 1 … 1 F 29554-3 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Pro...ion)   CONF Elementinhalt muss "Prozeduren und Maßnahmen" sein hl7:text SD.TEXT 1 … 1 M (Pro...ion)

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 .

Entry: Massnahme

	Template-Metadaten
Template-Typ	Entry
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
generelle Beschreibung	Dieser Abschnitt enthält Informationen über Massnahmen.
allg. Erläuterung
Verhältnis zu IHE	dt.Übersetzung oder Ergänzung oder neu
Ballotierungsstatus
Erweiterbarkeit	offen oder geschlossen

Beschreibung

Diese Act-Relationship-Klasse ist die Einleitung für die strukturierten, maschinenlesbaren Teile des Dokumentes. Sie stellt die Verbindung zwischen dem Text in einer Sektion und den Detailinformationen auf Level 3 her. Hierbei müssen die Maßnahmen innerhalb der Sektion stehen.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
6	act	procedure	ST	0..1	O
7	act	moodCode		1..1	F	Mood-Code <= EVN Der Mood-Code der hier spezifizierten Prozeduren ist immer EVN (Event), da es sich immer um stattgefundene Prozeduren handelt.
7	act	id	SET<II>	0..*	O	Prozedur-Identifikationsnummer Es ist empfehlenswert, jeder Einzelprozedur in einem Anwendungssystem eine Identifikation zuzuordnen (II). Damit wird eine gezielte Prozeduren-Kommunikation möglich, zum Beispiel das Zuordnen von Prozeduren beim Update / Änderung bzw. Löschen von Angaben.
7	act	code	CD CWE	1..1	R	Prozedur-Klassifizierung (Prozedurtyp) Hiermit wird der Typ der Prozedur spezifiziert. Für die Codierung der Prozeduren muss der OPS in der deutschen Fassung [ops2006], mit der OID 1.2.276.0.76.5.310 benutzt werden. Neben den verpflichtend anzugebenden OPS-Codes können auch zusätzlich alternative Codierungen spezifiziert werden. Diese werden als Übersetzung (translation) zusammen mit dem ursprünglichen Code angegeben.
7	act	@negationInd	BL	0..1	O	Negations-Indikator Wenn der negationInd auf true gesetzt ist, wird die Prozedur negiert/verneint. Das Modelattribut negationInd ist als Structural Attribute im root Element der Procedure zu finden (siehe unten). Wenn negationInd auf „true“ gesetzt ist, bedeutet dies, dass die Behandlungsmaßnahme als Ganzes negiert wird. Davon sind andere Eigenschaften wie Procedure.id oder Procedure.code und eventuelle Beteiligte nicht berührt. Diese Eigenschaften behalten ihre Bedeutung. Zum Beispiel bleibt der Autor ein Autor trotz einer negierten Prozedur. Eine negierte „Appendektomie“ beispielsweise bedeutet, dass der Autor bestätigt, dass diese nicht stattgefunden hat und dass er dies mit derselben Bestimmtheit sagen kann, als wäre die Behandlungsmaßnahme nicht negiert. Hinweis: Kann die Information des negationInd vom empfangenden System nicht korrekt angezeigt und verarbeitet werden, muss der dazugehörige Text von Level 2 angezeigt werden.
7	act	text	ED	0..1	O	ergänzende Erläuterungen zur Prozedur Hier können ergänzende (ausführlichere) Erläuterungen zur Prozedur angegeben werden, so vorhanden. Die Prozedur in Textform (Langtext) ist nicht der Text aus dem Codierschlüssel des OPS, sondern enthält zusätzliche Informationen.
7	act	statusCode		1..1	F	Statuscode <= completed Der statusCode der hier spezifizierten Prozeduren ist immer completed, da es sich immer um eine abgeschlossene Behandlungsmaßnahme handelt.
7	act	effectiveTime	IVL<TS>	0..1	O	Zeitangabe Prozedur Zeitangaben, von wann an (bis wann) die Prozedur durchgeführt wurde. Dies ist in der Regel ein Zeitpunkt.
7	act	priorityCode			O	Priorität
7	act	languageCode		0..1	O	Sprachcode
7	act	methodCode	SET<CE> CWE	0..*	O	Klassifizierung der Methode Hier wird die Methode näher spezifiziert, mit der die Behandlung durchgeführt wurde bzw. das Ergebnis erreicht wurde. Das Attribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet. Beim OPS Code ist die Behandlungsmethode bereits im Code enthalten.
7	act	approachSiteCode	SET<CE> CWE	0..*	O	Klassifizierung der Zugangsmethode Der anatomische Situs oder das System, über das die Behandlungsmaßnahme ihr Ziel erreicht. Zum Beispiel kann eine Nephrektomie als transabdominaler Eingriff oder mit retroperitonealem Zugang ausgeführt werden. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwen-det. Beim OPS Code ist die Zugangsmethode bereits im Code enthalten.
7	act	targetSiteCode	SET<CE> CWE	0..*	O	Klassifizierung der Zielgebiets Der anatomische Situs oder das System, auf das die Behandlungsmaßnahme abzielt. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet.

Beispiel

<entry>
  <!-- Massnahme -->
  <procedure moodCode='EVN' >
    <id root="9.9.9.9.9.9" extension ="abcde" />
    <code code="73761001" codeSystem="2.16.840.1.113883.6.96" displayName="Colonoscopy"/>
    <statusCode code='completed' />
    <effectiveTime value='201408121200' />
  </procedure>
</entry>

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

	Template-Metadaten
Template-Typ	Section
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
Generelle Beschreibung	Dieser Abschnitt enthält allgemeine Notizen.
allg. Erläuterung
Verhältnis zu IHE	neu
Ballotierungsstatus	in Arbeit
Erweiterbarkeit	offen

Beschreibung

In dem Abschnitt Notizen werden die medizinischen Informationen abgebildet, die keiner anderen Komponente zugewiesen werden können. Hierfür ist kein LOINC Code für die Sektion vorgesehen, das code Element wird weggelassen. Innerhalb des text Elementes kann eine der bekannten Strukturen verwendet werden.

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	section		1..1	M	Abschnitt mit Notizen
2	act	templateID		1..1	F
2	act	code		1..1	F
2	act	title		0..1	F	Notizen
2	act	text		1..1	M	Notizen in textueller Form

Vokabularien

keine

Beispiel

<component>
  <section>
    <templateID root=""/>
    <title>Notizen</title>
    <text>
             ....
    </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: Epikrise (Zusammenfassung des Aufenthalts)

Id	1.2.276.0.76.10.3021	Gültigkeit	2013‑09‑16
Status	Aktiv	Versions-Label
Name	Hospitalcoursesection	Bezeichnung	Zusammenfassung des Aufenthalts
Beschreibung Im Abschnitt Epikrise / Zusammenfassung des Aufenthalts wird ein spezieller zusammenfassender Rückblick, eine Interpretation des Krankengeschehens sowie der veranlassten Therapie, erfasst, welches für den weiterbehandelnden Arzt gedacht ist.
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Adaptation: Template 1.3.6.1.4.1.19376.1.5.3.1.3.5 Hospital Course Section (DYNAMIC) ref bccdapilot- Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr-
Beispiel	Beispiel <section>   <templateId root="1.2.276.0.76.10.3021"/>  <code code="8648-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <title>Epikrise</title>  <text>Sollten nach der empfohlenen Medikation mit Atemur die klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen Risikoprofil einen Kuraufenthalt für zwingend erforderlich. Ich bitte dann um Wiedervorstellung des Patienten.</text></section>
Item DT Kard Konf Beschreibung Label hl7:section (Hos...ion) hl7:templateId II 1 … 1 (Hos...ion) @root 1 … 1 F 1.2.276.0.76.10.3021 hl7:code CE 1 … 1 M (Hos...ion) @code CONF 1 … 1 F 8648-8 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Hos...ion)   CONF Elementinhalt muss "Epikrise" sein hl7:text SD.TEXT 1 … 1 M (Hos...ion)

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)

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

	Template-Metadaten
Template-Typ	Section
Template ID
generischeres Template
genutztes Templates	Laborbefund Entry Template
nutzende Templates
abgeleitete Templates
Schwester-Templates
generelle Beschreibung	Dieser Abschnitt enthält Informationen über Labordaten.
allg. Erläuterung
Verhältnis zu IHE	dt.Übersetzung oder Ergänzung oder neu
Ballotierungsstatus
Erweiterbarkeit	offen oder geschlossen

Beschreibung

Laborbefunde im Sinne von Ergebniszusammenfassungen und Beurteilungen für in-vitro Probenanalysen inklusive Mikrobiologie werden im elektronischen Arztbrief im Idealfall

• in Level 1 & 2 tabellarisch angegeben,
• in Level 3 codiert und mit dem entsprechenden Ergebniswert und Ergebniseinheit angegeben.

In der Regel liegen Laborergebnisse schon in hochstrukturierter Form in den Anwendungssystemen vor, der narrative Teil (z. B. tabellarische Darstellung) ist daher meist aus der strukturierten Information abgeleitet. Dies wird mit dem @typeCode DRIV (derived from) im entry Element angedeutet.

Laborergebnisse sind Spezialformen von Beobachtungen (Observation), weshalb zur Level 3 Wiedergabe von Laborergebnissen die entsprechende RIM-Klasse aus dem CDA Modell genutzt wird.

Beispiel

Test	Beschreibung	Wert	Einheit	Normbereich
ERY	Erythrozyten	4.37	10*12/l	4.2 - 6.2
HB	Hämoglobin	12.6	g/dl	14 - 18
...

<component>
  <!-- Labordaten -->
  <section>
    <code code="18723-7" codeSystem="2.16.840.1.113883.6.1"
          codeSystemName="LOINC"/>
    <title>24.09.2006: Laborwerte</title>
    <text>
      <paragraph>Wir berichten kurz zusammenfassend über die
                Laborergebnisse des obigen Patienten.</paragraph>
      <table border="1">
        <thead>
          <tr>
            <th>Test</th>
            <th>Beschreibung</th>
            <th>Wert</th>
            <th>Einheit</th>
            <th>Normbereich</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>ERY</td>
            <td>Erythrozyten</td>
            <td>4.37</td>
            <td>10*12/l</td>
            <td>4.2 - 6.2</td>
          </tr>
          <tr>
            <td>HB</td>
            <td>Hämoglobin</td>
            <td>12.6</td>
            <td>g/dl</td>
            <td>14 - 18</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: Abschließende Bemerkungen (Schlusstext)

Id	1.2.276.0.76.10.3034	Gültigkeit	2013‑12‑30
Status	Aktiv	Versions-Label
Name	Finalremarkssection	Bezeichnung	Abschließende Bemerkungen
Beschreibung	Ein am Ende des Briefes formulierter Freitext entsprechend einer Grußformel, z.B.: "mit kollegialen Grüßen
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 (Fin...ion) hl7:templateId II 1 … 1 (Fin...ion) @root 1 … 1 F 1.2.276.0.76.10.3034 hl7:code CE 1 … 1 M (Fin...ion) @code CONF 1 … 1 F X-FINREM @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 0 … 1 (Fin...ion) hl7:text SD.TEXT 1 … 1 M (Fin...ion)

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: Anhang (Beilagen)

Id	1.2.276.0.76.10.3037	Gültigkeit	2014‑08‑25
Status	Aktiv	Versions-Label
Name	Beilagen	Bezeichnung	Beilagen/Anhang
Beschreibung Sonstige Beilagen/Anhänge, außer denjenigen Dokumenten, die in „Patientenverfügungen und andere juridische Dokumente“ angegeben sind. Diese Section sollte (mind.) ein Entry enthalten. Die Anhänge können entweder als Referenz oder als direkte Inklusion des Objektes übermittelt werden.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3037
Klassifikation	CDA Section 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.4014 Containment Eingebettetes Objekt Entry DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr-
Beispiel	Beispiel <section>   <templateId root="1.2.276.0.76.10.3037"/>  <code code="X-OBSMED" displayName="Beilagen" codeSystem="2.16.840.1.113883.6.1"/>  <title>Beilagen/Anhänge</title>  <text>Bild vom Befund an der linken Hand</text>  <entry>     <!-- template 1.2.276.0.76.10.4014 'Eingebettetes Objekt Entry' (dynamic) -->   </entry></section>
Item DT Kard Konf Beschreibung Label hl7:section (Bei...gen) hl7:templateId II 1 … 1 (Bei...gen) @root 1 … 1 F 1.2.276.0.76.10.3037 hl7:code CE 1 … 1 M (Bei...gen) @code CONF 1 … 1 F X-OBSMED @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC)   Beispiel <code code="X-OBSMED" displayName="Beilagen" codeSystem="2.16.840.1.113883.6.1"/> hl7:title ST 1 … 1 (Bei...gen)   CONF Elementinhalt muss "Beilagen/Anhänge" sein hl7:text SD.TEXT 1 … 1 (Bei...gen) hl7:entry 0 … 1 Beinhaltet 1.2.276.0.76.10.4014 Eingebettetes Objekt Entry (DYNAMIC) (Bei...gen)

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 .

externe Referenz (Dokumente)

	Template-Metadaten
Template-Typ	Entry
Template ID
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Template
generelle Beschreibung
allg. Erläuterung	Verweis auf externe Dokumente
Verhältnis zu IHE	neu
Ballotierungsstatus
Erweiterbarkeit	offen

Beschreibung

Externe Dokumente können als unterstützende Informationsquellen in einem CDA Dokument referenziert werden. Dabei ist immer von einer Beobachtung (observation) die Rede, mit der das externe Dokument assoziiert ist.

Modell

Abbildung 27: ExternalDocument Klasse des CDA Modells zur Referenzierung externer Dokumente.

Die reference ActRelationship beinhaltet noch die Attribute @typeCode und @seperatableInd.

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Act				beliebige Aktivität aus dem Clinical Statement Pattern, an das eine externe Referenz angehängt werden kann. Aufgrund der möglichen Flexibilität an dieser Stelle ist das Template offen. Typischerweise wird hier aber eine observation verwendet.
2	act	@classCode		1..1	M
2	act	@moodCode		1..1	F	"EVN"
2	act	id		0..1	O
2	act	code		0..1	O
2	rel	reference
2	rel	@typeCode				Typ der Beziehung zum externen Dokument Hier muss angegeben sein, welche Typ Beziehung das externe Dokument zur referenzierenden Beobachtung hat. Hier nist zunächst nur der Typ SPRT (support) zugelassen, der ausdrückt, dass das externe Dokument einen unterstützenden Character hat.
3	rel	seperatableInd	BL	0..1	O	getrennt betrachtbares Dokumen Damit wird festgelegt, ob das externe Dokument losgelöst vom referenzierenden Dokument gesehen werden kann, oder ob es stetig mit diesem verbunden sein muss. Die Klasse ExternalDocument selbst gibt Auskunft über das referenzierte Dokument.
3	act	ExternalDocument		1..1	M	@classCode="DOC" und @moodCode="EVN"
4	act	id	II	0..1	O	Identifikation des extenen Dokuments Angaben dazu werden gewöhnlich über die Id des Dokuments gemacht.
4	act	code	CD CWE	0..1	R	Dokumententyp Über das code Modellattribut der ExternalDocument Klasse wird eine Typisierung des Dokuments vorgenommen.
4	act	text	ST	0..1	R	Mime-Type Andeutung des externen Dokuments Im text Element, modelliert als ED Datentyp, wird der Mime-Type des externen Dokuments angegeben.
4	act	setID	II	0..1	O	Set-Kennung des externen Dokuments
4	act	versionNumber	INT	0..1	O	Versionsnummer des externen Dokuments Mittels der Attribute setId und versionNumber kann eine Versionskennung des externen Dokuments erreicht werden (siehe hierzu auch Abschnitt 5.11).

Beispiel

<entry>
  <observation classCode="COND" moodCode="EVN">
    <code code="..." codeSystem="..." displayName="Diagnose"/>
    <value xsi:type="CD" code="..." ...>
      <originalText>
        <reference value="#a2"/>
      </originalText>
    </value>
    <reference typeCode="SPRT">
      <seperatableInd value="false"/>
      <externalDocument>
        <id root="1.2.3.4.5"/>
        <text mediaType="multipart/related">
          <reference value="CDA452365637.cda"/>
        </text>
        <setId root="1.2.3.4.6" extension="12345"/>
        <versionNumber value="1"/>
      </externalDocument>
    </reference>
  </observation>
</entry>

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 .

Umsetzungsstufen der Aktenkommunikation

Das Technical Framework von IHE ITI definiert wie Primärsysteme Patienteninformationen über die IHE XDS Schnittstellen einrichtungsübergreifend austauschen können. Die Patienteninformationen können dabei in unterschiedlichen Formaten und divergierender Granularität vorliegen. Die folgenden Abschnitte zeigen sechs Umsetzungsstufen für den Arztbrief auf. Die jeweiligen Umsetzungsstufen adressieren dabei unterschiedliche Standardisierungs- sowie Granularitätsgrade. Die einzelnen Umsetzungsstufen schließen sich gegenseitig nicht aus, sondern können parallel (oder nacheinander) umgesetzt werden. Im Sinne einer hohen Auswertbarkeit von medizinischen Daten ist die Migration auf höchster Umsetzungsstufe anzustreben.

Die Vermischung von verschiedenen Umsetzungsstufen innerhalb eines Dokumentes ist ebenso denkbar. Somit ist ein Dokument durch die verschiedenen Kombinationen von section- und entry-Level-Templates beliebig zu kombinieren. Siehe Grafik.

Beispiel: Wenn ein Arztbrief hauptsächlich Section Level Informationen beinhaltet, können dennoch Sektionen enthalten sein, die auch Entry Level Diagnosen abbilden.

Integrationsstufen für CDA

Umsetzungsstufe 1: Austausch proprietärer Dokumente

In der ersten Umsetzungsstufe werden proprietäre Daten (z.B. Arztbriefe in PDF oder auch WORD) über die IHE Schnittstellen ausgetauscht. Die benötigten IHE XDS Metadaten für die Document Registry werden entweder manuell erfasst oder im Idealfall aus dem System automatisch extrahiert. Diese Umsetzungsstufe wird bereits jetzt von allen Primärsystemen, die IHE XDS Schnittstellen umsetzen, unterstützt. Die Auswertbarkeit der Dokumente beschränkt sich hier auf die angegebenen IHE XDS Metadaten.

Damit wird aber noch keinerlei Information in CDA-Strukturen ausgedrückt.

Umsetzungsstufe 2: Austausch CDA Level 1(a) Dokumente

In dieser Umsetzungsstufe werden proprietäre Dokumente (z. B. Arztbrief als PDF) als CDA Level 1 Dokument über die IHE Schnittstellen der elektronischen Akte ausgetauscht. Die zur Registrierung benötigten IHE XDS Metadaten können automatisch aus dem CDA Header extrahiert werden. Ein CDA Level 1 Dokument ist ein Dokument welches einen strukturierten CDA Header umfasst. Die eigentliche medizinische Information wird entweder Base 64 Encoded in den CDA Body eingefügt (manchmal als Level 1a bezeichnet). Diese Umsetzungsstufe setzt voraus, dass Primärsysteme in der Lage sind ein proprietäres Dokument mit einem CDA Header zu versehen.

Die Auswertbarkeit der Dokumente beschränkt sich hier auf die angegebenen IHE XDS Metadaten und den strukturierten CDA Header Informationen. (Diese Möglichkeit gilt für alle weiteren Umsetzungsstufen.) In Abbildung 3 wird dies durch den grauen Bereich symbolisiert.

Umsetzungsstufe 3: Austausch CDA Level 1(b) Dokumente

In dieser Umsetzungsstufe werden die medizinischen Informationen in einem CDA Level 1 Dokument ausgetauscht. Hierbei wird zwar jegliche Information in einzelnen Abschnitten in XML-Darstellung repräsentiert, allerdings nur in rein textueller Form.

Umsetzungsstufe 4: Austausch CDA Level 2 Dokumente

In dieser Umsetzungsstufe werden die medizinischen Informationen in einem CDA Level 2 Dokument ausgetauscht. Die medizinischen Informationen werden in semantisch beschriebenen Abschnitten vorgehalten und diese Abschnitte sind über eine Kodierung erkennbar.

Diese Umsetzungsstufe setzt voraus, dass Primärsysteme in der Lage sind CDA Level 2 Dokumente zu erzeugen. Die CDA Level 2 Dokumente können geparst werden und es kann eine Auswertung bis hin zu Abschnittsebenen von Dokumenten durchgeführt werden.

Wünschenswert ist die Umsetzung in Form von Section Level Templates, d.h. die Abschnitte befolgen konkrete Vorgaben bzgl. der Inhalte.

Umsetzungsstufe 5: Austausch CDA Level 3 Dokumente

In dieser Umsetzungsstufe werden die medizinischen Informationen in einem CDA Level 3 Dokument ausgetauscht. Die medizinischen Informationen werden in strukturierten und semantisch beschriebenen Abschnitten (Section Level Templates) als strukturierte granulare Informationen vorgehalten (Entry Level Templates). Ein CDA Dokument in dieser Umsetzungsstufe bildet klinische Dokumente/aggregierte Informationen, wie sie aktuell in Primärsystemen vorliegen, feingranular strukturiert ab. Die CDA Level 3 Dokumente können geparst werden und es kann eine Auswertung bis hin zu den in den einzelnen CDA Level 3 Dokumenten dokumentierten granularen Informationen durchgeführt werden.

Zusammenstellung von Informationen in CDA-Dokumenten

Die CDA-Struktur kann benutzt werden, um verschiedene Arten von Informationen zusammenzustellen. Zum einen ist es möglich, unterschiedlichste Abschnitte zu benutzen, um bspw. einen Arztbrief mit Anrede, Fragestellung, Diagnosen, Befunden, etc. zu erzeugen. Genauso ist es möglich, einige wenige Abschnitte zu benutzen, um bspw. nur einen Kumulativbefund für Laborwerte zu erstellen. Genauso ist es dann auch möglich, in einem CDA-Dokument lediglich einen einzigen Abschnitt mit bspw. einer Diagnose oder einer Maßnahme unterzubringen. Man unterscheidet hier also zwischen aggegregierten und feingranularen Informationen.

Ein CDA Level 3 Dokument muss nicht zwangsweise ein klinisches Dokument/aggregierte Informationen abbilden. Es kann auch einzelne granulare Informationen beinhalten (z. B. eine Diagnose), die über Referenzen zu einem klinischen Dokument aggregiert werden können.
Beispiel: ein CDA Level 3 Dokument mit dem Dokumententyp „Diagnose“ umfasst eine Diagnose. Dieses CDA Level 3 „Diagnose“ kann einem CDA Level 3 Dokument mit dem Dokumententyp „Arztbrief“ zugeordnet sein.

Der Ansatz auch feingranulare Informationen als strukturiertes Dokument (bspw. über die IHE XDS Schnittstellen) zu übermitteln bietet folgende Möglichkeiten: Sowohl strukturierte und unstrukturierte Informationen werden über einheitliche Schnittstellen ausgetauscht. Dies reduziert die Schnittstellenkomplexität und verringert die Einstiegshürde, da viele Systemhersteller bereits den etablierten IHE XDS Standard umsetzen. Die Wahl der generischen IHE XDS Schnittstellen begünstigen zudem die Beständigkeit der Schnittstellen und bieten den Systemherstellern Investitionssicherheit. Die Granularität der Auswertung hängt von der Umsetzungsstufe ab und ist auch sehr feingranular möglich.

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

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 .

Beschreibung der Use Cases und Storyboards

Ein CDA Dokument, und ein Arztbrief im speziellen, kann in der realen Implementierung auf unterschiedliche Art und Weise kommuniziert werden. Die hierbei eingesetzten Softwarekomponenten agieren, je nach Leistungsumfang der kommunizierenden Partnersysteme, in unterschiedlichen Rollen, so genannten Akteuren. Für die Überleitung dieser Praxis in eine detailliertere Beschreibung werden sogenannte Use Cases und Storyboards, die eine Situation aus der Anwendersicht beschreiben, in eine mehr technische Darstellung, dem Interaktionsmodell, überführt. Es werden die häufigsten Use Cases beschrieben: der vollständige Arztbrief, die Änderung eines Arztbriefes und das Anhängen von weiteren Dokumenten und Objekten.

Use Case: Vollständiger Arztbrief („Alles ist da")

Der vollständige Arztbrief, d. h. alle relevanten medizinischen und demographischen Daten sind verfügbar, ist aus IT-Sicht der einfachste Fall. Der Arztbrief kann mit allen Inhalten und Referenzen in einem Arbeitsgang

• erstellt
• freigegeben und
• versendet werden.

Es steht dem Autor frei, unabhängig vom klinischen „Fall", die aus seiner Sicht zusammengehörigen medizinischen Ereignisse zu einem Patienten in einem Arztbrief zusammenzustellen. Ein Arztbrief bezieht sich somit auf exakt einen Patienten und auf eine „Episode" medizinischer Aktivitäten, womit das Konzept des HL7-Encounter gemeint ist, nämlich eine - aus der Sicht des Autors - zeitlich und logisch zusammengehörige Menge medizinischer Ereignisse. Eine Episode kann einem klinischen „Fall" entsprechen, kann aber auch mehrere „Fälle" ganz oder in Teilen oder umgekehrt nur Teilaspekte eines „Falls" beschreiben. Vor der Freigabe kann ein Arztbrief nicht versendet werden; diese Freigabe kann allerdings auch implizit durch das Versenden erfolgen. Einmal freigegeben, kann der Inhalt des Dokuments nicht mehr verändert werden; jedoch kann eine neue Version mit Bezug auf das Original erzeugt werden. Die Freigabe bezieht sich nicht auf den Inhalt eingebundener Dokumente, da diese zuvor unabhängig freigegeben wurden. Diese Schritte können, aber müssen nicht notwendigerweise zeitnah durchgeführt werden.

Storyboard: Vollständiger Arztbrief (POCD_SN000001DE)

Herr Paul Pappel, geboren am 17.12.1955 in Düsseldorf, wohnhaft Riedemannweg 59, 13627 Berlin soll am 30.06.2005 von der Inneren II der Heliosklinik Berlin Buch entlassen werden. Er befand sich seit dem 25.05.2005 in stationärer Behandlung.

Die Aufnahmediagnose lautete: Verdacht auf Lungenemphysem (J43.9 A).

Stationsarzt Dr. Müller geht am Vorabend der Entlassung an sein KIS-System und lässt sich eine Liste der am Folgetag zur Entlassung anstehenden Patienten anzeigen. Er ergänzt alle fehlenden Einträge in der Krankengeschichte und diktiert für den weiterbehandelnden Allergologen Dr. Schiwago und nachrichtlich an den Hausarzt Dr. No einen Entlassbrief mit den folgenden Inhalten:

Storyboard

Anamnese:

Seit Jahren wiederholt chronische Bronchitiden besonders bei kalter Luft. Bei Anstrengung exspiratorische Atemnot. Kontakt mit Haustieren.

Befund:

Pricktest:

Birke +++	Gräser-Mix +++	Hausstaubmilbe 1 +
Haselstrauch +++	Kammgras ++	Hausstaubmilbe 2 +
Erle +	Roggen ++	Schafwolle +
Hainbuche +	Quecke +	Rotbuche +
Eiche +
Keine Reaktion auf weitere Pollen, Katzen- / Hundehaare, Schimmelpilz.

Pulmo: Basal diskrete RGs

Cor: oB

Abdomen: weich, Peristalik+++

Muskulatur: atrophisch

Mundhöhle: Soor, Haarleukoplakie

Haut blass, seborrhoisches, Ekzem. Schleimhäute blass, Hautturgor herabgesetzt.

Neuro: herabgesetztes Vibrationsempfinden der Beine, distal betont. Parästhesien der Beine, PSR, ASR oB und seitengleich.

Diagnosen:

J45.0	G	Allergisches Bronchialasthma
J43.9	A	Ausgeschlossen: Lungenemphysem
J31.1	V	Verdacht auf Allergische Rhinopathie durch Pollen

Laborparameter:

Methode	Normbereich	25.06.05	26.06.05	28.06.05	29.06.05	Einheit
HB	13.5-16.5	12.7	13.3	13.6	11.9	g/dl
THRO	150-400	147	250	325	215	10*9/l
LEUKO	4-9.4	7.98	8.34	7.47	4.56	10*9/l
CD4_ABS	500-1000	30	%/ul
AMYL	6-34	40	U/l
G-GT	5-28	14	21	U/l

Röntgen:

• 26.05.2005: Röntgen Thorax: o.B.

Fremdbefunde: -

Histologie: -

Verlauf: -

Entlassungsbefund:

|Intensiviert behandlungsbedürftiges Bronchialasthma. Ich habe mit dem Patienten besprochen, zunächst die Peakflow-Werte zu optimieren und das Beschwerdebild zu beobachten.

Prognose: -

Therapien:

• Atemur, morgens 2x und abends 2x

Empfehlung: Sollten nach der empfohlenen Medikation mit Atemur die klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen Risikoprofil einen Kuraufenthalt für zwingend erforderlich. Ich bitte dann um Wiedervorstellung des Patienten.

Storyboard: Arztbrief vom Hausarzt (POCD_SN000007DE)

Diese Situation entspricht einem Brief vom Hausarzt.

Storyboard

CAVE:

ULCUSKRANKHEIT, Allergie auf DoloPosterine, AMOXICILLIN

Anamnese:

• Übliche Kinderkrankheiten, in der Kindheit Nierenerkrankung (?), sonst in früheren Jahren keine wesentlichen Vorerkrankungen.
• 1955 Appendektomie
• 1956 TE
• 1968 OP einer Pericardcyste
• Seit 1989 Hypertonie und latente Hypothyreose.
• 1989 Ulcus duodeni.
• 1977 und 1993 Polypektomie im Colon deszendens, Kontroll-Coloskopie 3/99 o. B.
• 11/01 kleiner Mediateilinfarkt re. unklarer Ätiologie.
• Seit Jahren Descensus uteri et vaginae.
• Hallux valgus li.
• Patelladysplasie Typ Wibert II. li.
• 6/02 Arthroskopie re. Knie.
• 9/03 Koloskopie mit Resektion eines Polypen im Colon ascendens.
• 1/2005 ED eines Bandscheibenprolaps L3/4 und einer Spinalkanalstenose L4/5.
• 5/2005 distale Radiusfraktur li. mit distaler Ulnafraktur. Versorgung mittels Platte und K-Draht.
• Seit 11/2005 manifester Diabetes mellitus Typ II.
• 9/2006 Polypektomie Colon deszendens, sonst Koloskopie o. B.
• 12/2008 Kontrollcoronarangiographie ohne akut interventionsbedürftigen Befund.
• 1/2010 Kontrollkoloskopie, Abtragung von zwei Polypenknospen.
• 04/2011 OP bei hochgradiger Spinalkanalstenose abgelehnt
• 5/2011 therapeutische LA lumbal erfolgreich
• 8/2011 mikrochirurgische Erweiterung WK LWK 1/2 bis 4/5.
• 11/2011 NPP L4/5: konservativ.
• 12/2011 Distorsion OSG re.
• 1/2012 vaginale Hysterektomie bei Uterus myomatosus.
• 3/2012 ED einer mittelschweren Coxarthrose re.
• 06/2012 bei initialem V. a. dementielle Entwicklung Ausschluss NPH oder cerebale Raumforderung (CT).
• 9/2012 erneute Nukleotomie mit Spondylodese L4/5

Dauerdiagnosen:

• Diabetes mellitus – gesichert –
• Depressive Episode
• Hypertonie
• Nicht näher bezeichnete Hämaturie
• Lumboischialgie
• Zust. nach Hirninfarkt nicht näher bezeichnet re.
• Hypothyreose nicht näher bezeichnet
• Koronare Herzkrankheit
• Jodmangelbedingte mehrknotige Struma endemisch
• Chronisches Schmerzsyndrom
• Spinalkanalstenose: Lumbalbereich
• Varicosis bds.
• Sonstige sekundäre Koxarthrose re.
• Drop Attacks

Dauermedikation

	Morgens	Mittags	Abends	zur Nacht
Bisoprolol	1
ASS 100		1
Allopurinol 300	1
Amitriptylin 75			1
Jodid 200	1
Simvastatin 40			½

Letzte Änderung am: 13.11.2012

Kontrolluntersuch

HZV-DAK

DMP Diabetes mellitus

Impfungen:

Datum	Art	Chargennummer
19.2.13	Td-pur Impfung (Tetanol/Diphterie).	063311A (D)
8.11.02	Pneumopur i.m.	HP27610 (D)
24.3.00	2. Havrix 1440 i.m.	VHA604C6 (St)
23.9.99	1. Havrix 1440 i.m.	VHA551B6

Use Case: Nachtragen / Anhängen weiterer Information, Ersetzen eines vorläufigen Arztbriefs

Ausgangssituation: Der Arztbrief wurde bereits vorher in Teilen erstellt und versendet (vorläufiger Arztbrief), jedoch fehlten bislang einige Informationen, wie zum Beispiel Diagnosen oder Befunde. Der ursprüngliche Arztbrief war also deswegen als „vorläufig" gekennzeichnet, jedoch so bereits freigegeben und wurde als Vorgängerversion schon versendet.

Sobald die bisher fehlende Information vorliegt, kann der „vorläufige" Arztbrief im Rahmen einer neuen Version ergänzt, freigegeben und als Ganzes erneut versendet werden. Diese Dokumentenbeziehung wird in CDA Release 2 als „replacement" bezeichnet. Es entsteht also ein neues Dokument, das an den "vorläufigen" Arztbrief durch eine replacement-Beziehung angehängt ist.

Beim Empfänger ist der Bezug des vollständigen Arztbriefs zum vorherigen erkennbar, es handelt sich jedoch um zwei Dokumente mit unterschiedlicher Identität.

Storyboard: Revision Arztbrief Teil 1 (POCD_SN000002DE)

Im ersten Schritt kommt dieses Storyboard der Übersendung eines vorläufigen Arztbriefes gleich. Am Tag der Entlassung von Frau Emma Erle, 30 Jahre, stellt Dr. Maier fest, dass die Ergebnisse der letzten Laboruntersuchung noch nicht vorliegen. Da er dennoch zeitgleich mit der Entlassung einen Arztbrief an Dr. Schulze, dem Hausarzt von Frau Erle, schicken möchte, entscheidet er sich, in seinem IT-System einen "vorläufigen Arztbrief" zu erstellen. Dr. Maier wählt hierzu aus den ihm vorliegenden klinischen Befunden alle ihm relevant erscheinenden Informationen aus. Die Diagnosen übernimmt er inklusiv der in seinem System vorgenommenen Kodierungen direkt in den Arztbrief. Den OP-Bericht kürzt er und streicht alle Informationen, die ihm für die Weiterbehandlung nicht relevant erscheinen, die CT-Befunde ergänzt er dagegen um eine zusätzliche Interpretation. Anstelle der noch ausstehenden Laborbefunde fügt er einen entsprechenden Vermerk und sendet den vorläufigen Arztbrief an Dr. Schulze.

Storyboard

Anamnese:

Seit der Geburt ihres Kindes vor 5 Monaten klagte die Patientin über Schmerzen im LWS-Bereich mit Ausstrahlung in das rechte Bein bis hin zur Großzehe. Eine konservative ambulante Therapie habe bisher keinen Erfolg gebracht. Die allgemeine Vorgeschichte ist unauffällig.

Befund:

Bei der Untersuchung zeigte die Patientin eine aufrechte Haltung, sowie einen zügigen, sicheren und koordinierten Gang, ohne Gehhilfsmittel. Ein leicht schmerzbetontes Hinken bei Vollbelastung beider Beine war rechtsseitig zu beobachten.

Die WS ist gerade aufgebaut, bei einer deutlichen Hyperlordose der LWS. Die paravertebrale Rumpfmuskulatur war beidseitig kräftig entwickelt. Ein Druck- oder Klopfschmerz war nicht auszulösen. Der Zehenspitzen- und Hackengang war beidseitig normal durchführbar, ebenso wie der Einbeinstand beidseits. Die Seitwärtsneigung nach rechts war endgradig schmerzhaft, nach links unauffällig durchführbar und die Rotation beidseitig unauffällig möglich. Die Reklination war ohne Schmerzen durchzuführen, die Inklination jedoch deutlich mit Schmerzen verbunden, der FBA reichte bis zu den Kniegelenken. Das Laseguèsche Phänomen war rechts bei 60° positiv, links endgradig positiv. Der PSR war beidseits seitengleich, ebenso der ASR seitengleich und normal auslösbar.

Sensibilitätsstörungen fanden sich nicht, ebenso wenig motorische Störungen. Die Beweglichkeit der unteren Extremitätengelenke war in allen Ebenen frei möglich und die Beinlänge seitengleich.

Diagnosen:

M51.3+G51.1* G L: Wurzelkompression S1 durch subligamentär sequestrierten BSV parasacral li. Laborparameter: Folgen noch!

Röntgen:

Kernspintomographie der LWS:

1. Im Segment L4/5 mäßige Höhenminderung des Zwischenraums mit Signalabsenkung innerhalb des Bandscheibengewebes als Zeichen der Degeneration.

Es resultiert eine tropfenförmige, noch subligamentär situierte Bandscheibenherniation, die zu einer ovalären Impression des Duralsacks führt. Die intraformalinaren Nervenwurzeln kommen symmetrisch regelrecht zur Darstellung.

2. Im Segment L4/S1 ebenfalls Signalabsenkung innerhalb des Bandscheibengewebes, bei noch erhaltener Höhe des Zwischenwirbelraums: Dehydralation des Nucleus pulposo. Schmale kragenförmige Protrusion mit angedeuteter Parottierung des Duralsacks.

3. In L 3/4 „bulging disc"

4. In den übrigen Etagen keine Besonderheiten

Fremdbefunde: -

Histologie: -

Verlauf: -

Entlassungsbefund:

Keine sensomotorischen Ausfälle

Prognose: -

Therapien:

OP am 20.12.2005: Nach Einleitung der Intubationsnarkose Lagerung der Patientin in Bauchlage und Kniehockstellung. Palpatorische Höhenlokalisation über den Dornfortsätzen von LWK 5 / SW 1 von links und Anlage eines medialen Hautschnittes. Präparation der subkutanen Fettschicht, Darstellung der muskulären Fascie. lncision derselben und Abschieben der langen Rückenmuskulatur vom medialen Fascienblatt nach lateral. Nochmals Überprüfung der korrekten Höhe. Nachcaudal lässt sich kein weiteres interlaminäres Fenster mehr tasten. Nach Einsetzen des selbsthaltenden Williamssperre erfolgt unter Zuhilfenahme des Operationsmikroskopes die erweiterte interlaminäre Fensterung. Intraspinal findet sich epidurales Fettgewebe, nach vorsichtiger Präparation und Darstellung der nach dorso-medial deutlich verlagerten komprimierten Nervenwurzel stellt sich in Höhe des Bandscheibenraumes ein großer, breitbasiger subligamentär sequestrierter Bandscheibenvorfall dar. Nach vorsichtiger Medialisierung der nervalen Strukturen und nochmals Erweiterung der interlaminären Fensterung scharfe lncision des hinteren Längsbandes. Es lässt sich ein sequestierter Bandscheibenvorfall problemlos entfernen. Danach sind die nervalen Strukturen bereits deutlich entspannt, jetzt Eingehen in den dazugehörigen Bandscheibenraum. Es erfolgt die Nukleotomie. Es lässt sich jede Menge degenerativ verändertes Bandscheibengewebe entfernen. Von medio-caudal her findet sich noch subligamentär ein weiterer kleinerer Bandscheibensequester. Nach kranial hin scheint das hintere Längsband angehoben, es lässt sich jedoch auch von medio-caudal her vom festen Osteosacrum eine kleine osteochondrotische Randzacke tasten. Diese kann teilweise auch entfernt werden. Nach mehrmals Spülen mit physiologischer Kochsalzlösung finden sich keine freien Bandscheibensequestermaterialen mehr. Nochmals Darstellung der freien nervalen Strukturen mit Hilfe des gebogenen Dissektors. Anschließend kann die Operation beendet werden durch schichtweisen Wundverschluss, Muskelfasciennaht, Subcutannaht, lntracutannaht. Steriler Verband.

Empfehlung:

Um die Rumpfmuskulatur nach der OP zu stärken, die Haltung zu verbessern und weiteren Beschwerden vorzubeugen empfehlen wir krankengymnastische und muskelkräftigende Übungen in Einzeltherapie, eine Haltungsschulung, Bewegungsbäder, Rückenschwimmen, Fango und Massage für die LWS, aussparend den S1-Bereich, sowie Massagen für Schulter- und Nackenbereich.

Storyboard: Revision Arztbrief Teil 2 (POCD_SN000003DE)

Dr. Schulze erhält den vorläufigen Arztbrief über den Krankenhausaufenthalt seiner Patientin Emma Erle in seinem Eingangsordner. Er erkennt sofort, dass es sich um eine vorläufige und damit unvollständige Version handelt. Dennoch verschafft er sich einen ersten Überblick über die Krankheitssituation von Frau Erle. 3 Tage später erhält Dr. Maier einen Hinweis in seinem IT-System, dass neue Laborbefunde für Frau Erle vorliegen.

Storyboard

Laborparameter:

Der CHOL-Wert war mit 294 mg% leicht erhöht, sowie die BSG mit 18/42 leicht erhöht. Normalwertig waren rotes und weißes Blutbild, harnpfl. Substanzen, Transamiasen, LDH, GGT, TG, RF, CRP, ASL, Elektrolyte, BZ-nüchtern und der Quick-Wert. In Urinsediment fanden sich 70-80 Leucos.

Er ruft den vorläufigen Arztbrief für Frau Erle auf und erzeugt eine neue, revidierte Version, in die alle Informationen aus dem vorläufigen Arztbrief 1:1 übernommen werden. Zusätzlich wird eine entsprechende Referenz auf die Vorgängerversion in den Arztbrief eingefügt. Anschließend löscht Dr. Maier den Vermerk über die fehlenden Laborwerte und ersetzt sie durch eine Zusammenfassung der wichtigsten Laborergebnisse sowie eine Kommentierung dieser Parameter. Vor dem Absenden ändert Dr. Maier noch den Typ des Arztbriefes von "vorläufiger Arztbrief" auf "endgültiger Entlassbrief" und schickt eine zusätzliche Kopie an Frau Erle, da diese ihn darum gebeten hat, direkt über die endgültigen Ergebnisse informiert zu werden. Dr. Schulze erhält den endgültigen Entlassbrief in seinem Eingangsordner. Da die Vorgängerversion bekannt und bereits in seinem IT-System abgelegt ist, kann er einen Abgleich zwischen beiden Versionen durchführen und sich die neuen Änderungen in der aktuellen Version graphisch hervorgehoben anzeigen lassen. Da er den vorläufigen Arztbrief bereits gelesen hat, überfliegt Dr. Schulze nur noch die geänderten Abschnitte und hat nun ein klares Bild über den gesamten Klinikaufenthalt Frau Erle.

Use Case: Referenzieren von Arztbriefen (Einbinden)

Ein bestehender, bereits freigegebener Arztbrief wird in einen in Erstellung befindlichen zweiten Arztbrief durch Referenzierung eingebunden. Der referenzierte Arztbrief selbst bleibt dabei unverändert. In beiden Arztbriefen wird auf denselben Patienten Bezug genommen. Die Autoren und Empfänger der beiden Arztbriefe sind typischerweise verschieden.

Storyboard: Referenzierung im Arztbrief Teil 1 (POCD_SN000004DE)

Im ersten Schritt kommt dieses Storyboard der Übersendung eines Kurzarztbriefes (in diesem Falle Informationen bei Überweisung) gleich. Der Hausarzt Dr. Huber überweist seine Patientin Birgit Birke an einen Facharzt der Dermatologie mit der Verdachtsdiagnose eines subkutanen Melanoms am Übergang Hinterkopf Hals. Der Dermatologe erhält vom Hausarzt einen Kurzarztbrief mit Medikation (Penicillin, Insulin), Anamnese und Diagnose (Borreliose, eine Woche zuvor) etc.

Storyboard

Anamnese:

Die 63 jährige insulinpflichtige Diabetikerin stellt sich im Rahmen einer Borliosebehandlung mit einer Hautveränderung am Übergang zwischen Hinterkopf und Hals vor. Nach Aussage der Patientin soll sie sich innerhalb der letzten 3 Monate gebildet haben.

Befund:

20.12.2005: Oberflächlich spreitende, unregelmäßige, Hautveränderung am Übergang vom Hinterkopf zum Hals mit einem Durchmesser von ca. 1 cm, Unregelmäßige, überwiegend dunkle Hautverfärbung. Verhärtet.

Diagnosen:

E11.90 G Nicht primär insulinabhängiger Diabetes mellitus (Typ-2-Diabetes) ohne Komplikationen, nicht als entgleist bezeichnet

A69.2 G Borreliose

C43.4 V Verdacht auf Melanom am Übergang vom Hinterkopf zum Hals

Laborparameter: -

Röntgen: -

Fremdbefunde: -

Histologie: -

Verlauf: -

Entlassungsbefund: -

Prognose: -

Therapien:

Huminsulin Basal (NPH) Fertigpen 3 ml, morgens und abends, je eine Spritze Penicillin V1 Mega von ct, morgens, mittags und abends, je eine Filmtablette

Empfehlung: -

Storyboard: Referenzierung im Arztbrief Teil 2 (POCD_SN000005DE)

Im zweiten Schritt kommt dieses Storyboard der Übersendung eines weiteren Kurzarztbriefes (in diesem Falle Informationen bei Überweisung) mit angehängtem Arztbrief gleich.

Der Dermatologe untersucht die Patientin und fertigt zusätzlich ein Bild der fraglichen Region an, die rötlich gefärbt ist. Er kommt zu der Entscheidung, dass eine Entfernung der Wucherung ambulant/stationär im Krankenhaus erfolgen soll und weist die Patientin ins Marienhospital ein.

Dabei übersendet er dem Krankenhaus seinen Arztbrief mit Bild und hängt den Kurzarztbrief des Hausarztes an. Zusätzlich sendet der Dermatologe dem Hausarzt eine Kopie des Briefes.

Storyboard

Anamnese:

Siehe Arztbrief des Hausarztes in der Anlage

Befund:

21.12.2005: Oberflächlich spreitende Hautveränderung am Übergang vom Hinterkopf zum Hals mit einem Durchmesser von 1 cm.

Diagnosen:

C43.4 V Verdacht auf Melanom am Übergang vom Hinterkopf zum Hals Laborparameter: -

Röntgen: -

Fremdbefunde: -

Histologie: -

Verlauf: -

Entlassungsbefund: -

Prognose: -

Therapien: -

Empfehlung: Ambulantes oder stationäres Entfernen der Hautveränderung und histologische Bestimmung.

Storyboard: Referenzierung im Arztbrief Teil 3 (POCD_SN000006DE)

Diese Situation entspricht einem Entlassbrief mit angehängten Arztbriefen.

Im Krankenhaus wird vor dem operativen Eingriff zur Abklärung der Beteiligung des Schädelknochens eine Röntgenaufnahme gefertigt und anschließend die gutartige Wucherung ambulant entfernt. Auf Wunsch der Patientin wird diese zur Nachbehandlung an den Hausarzt überwiesen.

Dabei wird ein Entlassbrief zur Nachbehandlung für den Hausarzt erzeugt. Am Entlassbrief ist der Arztbrief des Dermatologen angehängt. Der Dermatologe erhält eine Kopie.

Storyboard

Anamnese:

bekannt

Befund:

28.12.2005: Unklarer Befund bei Abdomensonographie zur Detektion viszeraler Metastasen

Diagnosen:

C43.4 A Melanom D36.9 G Melanom, benigne

Laborparameter: -

Röntgen:

29.12.2005: Ein CT hat keinen Metastasenbefund ergeben.

Fremdbefunde: -

Histologie:

06.01.2006: Kein Hinweis auf ein malignes Melanom bei der eingesendeten Körpersubstanz.

Verlauf: -

Entlassungsbefund:

Bei der uns zum operativen Eingriff eingewiesenen Patientin konnte der Verdacht auf ein malignes Melanom ausgeschlossen werden. Die Patientin wurde darauf hingewiesen, bei weiteren Hautveränderungen sofort einen Arzt aufzusuchen.

Prognose: -

Therapien:

30.12.2005: Entfernung des Hautbereiches ohne Komplikationen, Einsendung zur histologischen Befundung.

Empfehlung:

Nachversorgung des Eingriffs mittels Heilsalbe mit Wirkstoff Panthenol nach Bedarf.