Arztbrief 2006

{{{Title}}}

Arztbrief 2006

Implementierungsleitfaden

vorgelegt von:
.

Entwurf

Version:	1.5
Datum:	XX. XXXXXXXXX 2006
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2006: HL7 Deutschland

Initiative Intersektorale Kommunikation

Arztbrief

auf Basis der HL7 Clinical Document Architecture Release 2

FÜR DAS DEUTSCHE GESUNDHEITSWESEN

• Implementierungsleitfaden –

Version 1.90 Stand: 27.09.2006

Dokumenten-OID: 1.2.276.0.76.3.1.13.7.6

VHitG

IMPLEMENTIERUNGSLEITFADEN

ARZTBRIEF

AUF BASIS DER HL7 CLINICAL DOCUMENT ARCHITECTURE RELEASE 2

FÜR DAS DEUTSCHE GESUNDHEITSWESEN

vorgelegt vom

VHitG

Geschäftsstelle: Verband der Hersteller von IT-Lösungen für das Gesundheitswesen VHitG Neustädtische Kirchstr. 6 10117 Berlin

Ansprechpartner

Andreas Kassner (email: andreas.kassner@vhitg.de) VHitG Geschäftsstelle

Kai U. Heitmann (email: hl7@kheitmann.nl) Heitmann Consulting and Services Sciphox Arbeitsgemeinschaft GbR mbH HL7-Benutzergruppe in Deutschland e.V.

Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf dem Abstimmungspaket 11 und der Normative Edition 2005 von HL7 Version 3 beruhen, für die © HL7 Inc gilt.

Disclaimer

Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann der VHitG keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.

Dokumenteninformation

Status Finale Version nach Abstimmung

Revisionsliste

Version	Autor	Inhalt	Datum
0.10	GH	Draft	22-07-2005
0.20	KH	Rationale aus SCIPHOX WD15 teilweise übernommen & angepasst, + dynamisches Modell eingefügt, SCIPHOX Nutzungshinweis	05-08-2005
0.50	KH	Header und (teilweise) Body Definitionen zugefügt	03-10-2005
0.51	KH	Header weiter vervollständigt auf Basis der Rückmeldungen; Body weiter ausgeführt; Dynamisches Modell	23-10-2005
0.60	KH	Header weiter vervollständigt;	05-11-2005
0.70	KH	Body vervollständigt; Zuarbeiten von GH, EG und RF verarbeitet	06-11-2005
0.72	KH, AK	Dynamisches Modell und Body weiter ausgearbeitet	08-11-2005
0.80	KH	Header und Body bearbeitet auf Basis der Besprechung und der Rückmeldungen	09-11-2005
0.82	KH	Body	12-11-2005
0.83	KH	Graphische Darstellungen, Revision dynamisches Modell, Diagnosen Level 2 und 3 detaillierter	13-11-2005
0.90	KH	Procedure hinzugefügt, Modellbeschreibung, Kommentare aus diversen Emails verarbeitet	27-11-2005
0.98	KH	Use Cases vervollständigt und umgestaltet, OID Szenario und Links (Verweise Multimedia) hinzugefügt, diverse Kommentare verarbeitet, Hinweis Stabilität der Standards hinzugefügt, Präambel geändert	04-12-2005
0.99	KH, AK	Diverse interne Kommentare verarbeitet (Siehe Kommentarblatt vom 2005-12-11	11-12-2005
1.0	AK	Letzte interne Kommentare verarbeitet (Siehe Kommentarblatt vom 2005-12-15	15-12-2005
1.10	KH	Kommentare verarbeitet auf Basis des Abstimmungsverfahren Sciphox	18-02-2006
1.11	KH, AK	Kommentare verarbeitet auf Basis des Abstimmungsverfahren VHitG und Sciphox	19-02-2006
1.12	KH, AK	Korrekturen Text aus Abstimmungsverfahren	21-02-2006
1.20	KH	Regeln ergänzt, informative Kapitel versetzt	02-03-2006
1.21	KH	OIDs, code mit nullFlavor ergänzt, Tippfehler beseitigt.	23-03-2006
1.22	KH	listType ergänzt, Kapitel 8 ergänzt, Beispiele entfehlert	27-03-2006
1.23	KH	OIDs nachgetragen und korrigiert, COV und COVPTY ergänzt bei Participants, mailto: ergänzt bei telecom	03-04-2006
1.50	KH	Technische Korrekturen nach Testtagen mit Anbietern; Regelnbezeichnungen von Durchnumerierung auf Vierbuchstaben-Identifikation geändert	22-05-2006
1.90	KH	Labor Level 3 hinzugefügt	27-09-2006

Editoren Kai U. Heitmann (KH), Heitmann Consulting & Services Andreas Kassner (AK), VHitG e.V.

Autoren Kai U. Heitmann (KH), Heitmann Consulting & Services Andreas Kassner (AK), VHitG e.V. Erich Gehlen (EG), Duria eG Hans-Joachim Görke, GSD mbH Georg Heidenreich (GH), Siemens Medical Solutions

Mit Beiträgen von Ralf Franke, Bamberg, DOCexpert Computer GmbH Gunther Hellmann, Berlin, ID Berlin GmbH Torsten Riechert, Trier, GWI Research GmbH Michael Saxler, Eltville, MCS AG

Autoren und Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche Das vorliegende Dokument wurde vom Verband der Hersteller von IT für das Gesund¬heits¬wesen (VHitG) entwickelt. Die Nachnutzungs- bzw. Veröffentlichungs¬ansprüche sind nicht beschränkt. Der Inhalt dieser Spezifikation ist öffentlich. Er basiert auf den Spezifikationen der Arbeitsgemeinschaft SCIPHOX GbR mbH und dem national adaptierten HL7-Standard der „Clinical Document Architecture (CDA)". Näheres unter http://www.sciphox.de, http://www.hl7.de und http://www.hl7.org. Die Erweiterung oder Ableitung der Spezifikation, ganz oder in Teilen, ist der Ge¬schäfts¬führung des VHitG und der Arbeitsgemeinschaft SCIPHOX GbR mbH schriftlich anzuzeigen. Für alle von der Arbeitsgemeinschaft SCIPHOX GbR mbH veröffentlichten Dateien mit einem CDA-Bezug gilt ferner: Alle von der Arbeitsgemeinschaft SCIPHOX 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, ver¬zichten. Näheres finden Sie unter http://www.sciphox.de, http://www.hl7.de und http://www.hl7.org. Alle auf nationale Verhältnisse angepassten und veröffentlichten SCIPHOX/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 und der SCIPHOX GbR mbH, zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.

Einleitung

Aufbau dieses Implementierungsleitfadens

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 Nachrichten 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 XML-basierte Implementierung.

HL7 und Referenz-Modelle

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.

Abbildung 1: RIM Basisklassen

Konzept und Begründung

Zweck

Im Rahmen der Kommunikation zwischen Niedergelassenen und Krankenhäusern ist der Arztbrief als „Kondensat ärztlichen Handelns" von überragender Bedeutung. Das Ziel dieses Dokuments ist die Beschreibung der elektronischen Übermittlung von Arztbriefen. 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. Im Rahmen der VHitG-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 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 vom Dokumenttyp „Arztbrief" abgedeckt. 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 vom sendenden System 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.

Fokus

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. Somit 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.

Grundlagen

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 Kommunikationsprotokoll 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. Allgemein gelten für CDA-Dokumente sechs Kerneigenschaften

• Persistenz
• Verantwortlichkeit für die Verwaltung des Dokuments
• Signaturfähigkeit
• Kontext
• Ganzheit des Dokuments
• Lesbarkeit

Diese werden in Abschnitt 3.3 „Eigenschaften..." genauer erläutert.

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) \[sci\]
• HL7 v3 , CDA Rel. 2 „CDA Care Record Summary Implementation Guide" \[hl7crs\]
• Use Cases for Medical Summaries, L. McNight, IHE PCC, 2005 \[ihepcc\]
• Der französische „Guide d\’implémentation du Volet Médical au format CDA Release 2 – Niveau 3" \[volmed\]
• e-MS. Implementierungsleitfaden CDA (Level 2 und 3), Kanada \[ems\]
• IHE Laboratory Technical Framework, Supplement „Sharing Laboratory Reports (XDS-LAB)" \[ihelab\]

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.

Konformanz

Ein zu diesem Implementation Guide konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein kon¬former "stationärer Entlassbrief" kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäfts¬regeln" im weiteren Text dieses Dokuments. Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten (und Nachrichten) wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das zum Arztbrief gehörige Schema ist das unveränderte generische, offizielle CDA Release 2 Schema (siehe Anhang 8.1). 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. Solange der HL7-Template-Formalismus noch in Arbeit ist, ermöglicht CDA die Identifikation der verwendeten Templates bzw Implementation Guides vom CDA-Dokument aus mittels eines eindeutigen – noch von SCIPHOX zu vergebenden – Identifikators. Der Einsatz von so genannten „temp¬lateId" 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.

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 ist ANSI Standard seit Mai 2005. Dieser Leitfaden fußt auf ANSI/HL7 CDA R2-2005, derweil gehen die Entwicklungen bei CDA weiter und Implementierungen (so auch die auf diesem Leitfaden basierten) liefern Verbesserungsvorschläge. Die verwendeten Datentypen sind mit den Festlegungen in „XML Implementation Technology Specification - Data Types Release 1" schon länger ANSI Standard (seit der Jahreswende 2004/05). Diese sind auch im Leitfaden "HL7 Version 3 Datentypen und CMETs Leitfaden für das Deutsche Gesundheitswesen" \[dtcmetv3-hl7de\] veröffentlicht.

Bezug zum HL7 Version 3 Nachrichtenaustausch

Das CDA-Informationsmodell stellt eine Beschreibung für die Nutzinhalte von medizinischen Dokumenten zur Verfügung. Dabei wird aber explizit kein Hinweis auf den elektronischen Informationsaustausch von CDA-Doku¬men¬ten 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 Koexitstenz 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.

CDA Release 2 – Konzept und Modellbeschreibung

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. Darüber hinausgehend wäre das andere Ende die Anwendungs-Inter¬operabilität. Dies beinhaltet die Wiederverwendbarkeit von Informationen, Kontext-abhängige Analysemöglichkeiten und angemessenes Speichern und Verwalten von klinischen Dokumenten.

CDA Standard

Die Clinical Document Architecture (\[ansicdar2\]) 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 (\[XML\]) benutzt. CDA wird entwickelt von HL7 (Health Level Seven), einem der bedeutungsreichsten internationalen Standardentwickler 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 \[cdaconf1, cdaconf2\]). 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>,

, 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 Seite 84 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 durch Persistenz, also dauerhafte Existenz in den sendenden oder empfangenden Systemen gekennzeichnet. Dies kennt man auch aus der Papierwelt (klinische Dokumentation hat „Dokumenten-Charakter").

Verantwortlichkeit für die Verwaltung des Dokuments

Eine Organisation zeichnet 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.

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 Style¬sheets) sichtbar machen kann. Dafür gilt zudem:

• Es muss einen deterministischen Weg für einen Empfänger geben, den authentifizierten Inhalt sichtbar 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 einzigen 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 authentifiziert oder 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 Body 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.

Abbildung 2: 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), Body Entries (maschinenauswertbare Detailinformationen). Schließlich können auch externe Referenzen aufgeführt sein.

Abbildung 3: 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, eine Andeutung des Typs 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 Mechanismen 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. Body 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.

Abbildung 4: 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 Statements bezeichnet und findet sich in gleicher oder ähnlicher Form auch in HL7-Version 3-Nachrichten zu Anforderungen und Befunden etc. wieder. Insgesamt sind in der Auswahl folgende Klassen verfügbar.

• observation, eine (kodierte) Beobachtung, z. B. ein Befund oder eine Diagnose
• procedure, eine Prozedur, z. B. eine Operation, eine andere Behand¬lung, rein diagnostischer Eingriff
• encounter, Angaben zu früheren, jetzigen oder geplanten Patienten¬kontakten
• substanceAdministration, medikamenten-bezogene Angaben im Sin¬ne von stattgefundenen (Medikamentenanamnese) oder geplanten Medikamentengaben
• supply, zur Verfügungstellung von Material oder Medikamenten¬verabreichungen
• organizer, zur Gruppierung von anderen CDA Entries (Batterien, Cluster)
• observationMedia, multimedialer Inhalt als Teil des Dokuments
• regionOfInterest, Kennzeichnung einer Hervorhebung eines Teil¬aspekts 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.

Abbildung 5: Clinical Document Architecture Release 2.0

Dynamisches Modell

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)

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:

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.

Use Case: Nachtragen / Anhängen weiterer Information

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.

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.

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.

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.

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 ist 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.

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.

CDA R2 Dokument und Header

Dokumentenstruktur

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 namespace-Präfixe nicht genutzt. 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 Clinical¬Document, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument
    xmlns="urn:hl7-org:v3"
    xmlns:voc="urn:hl7-org:v3/voc"
    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>

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

Zentrale Klasse des Clinical Document Architecture Modells ist die ClinicalDocument Klasse. Die zugehörigen Attribute, so wie sie in den hier beschriebenen Anwendungsszenarien zur Anwendung kommen, werden im weiteren Verlauf dieses Leitfadens beschrieben. Dazu werden XML Fragmente als Beispiele gezeigt.

Abbildung 6: Clinical Document Klasse Die folgende Tabelle gibt eine Übersicht über die in diesem Leitfaden besprochenen CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität.

Element (Sequenz)	Datentyp	Bedeutung	Kard.
ClinicalDocument Klasse
realmCode	CS	–nicht verwendet–	0..\*
typeId	II	-konstant-	1..1
templateId	II	Template Id für das ganze Dokument	0..1
id	II	Dokumenten-Id	1..1
code	CE	Dokumententyp	1..1
title	ST	Zusätzliche Dokumententyp-Bezeichnung	0..1
effectiveTime	TS	Erstellungsdatum des Dokuments	1..1
confidentialityCode	CE	Vertraulichkeitsgrad	1..1
languageCode	CS	Sprache des Dokuments	0..1
setId	II	Set-Kennung	0..1
versionNumber	INT	Versionsnummer	0..1
copyTime	TS	–nicht verwenden–	0..1
Participations
recordTarget		Record Target	1..\*
author		Author	1..\*
dataEnterer		Data Enterer	0..1
informant		Informant, –noch nicht verwendet–	0..\*
custodian		Custodian	1..1
informationRecipient		Information Recipient	0..\*
legalAuthenticator		Legal Authenticator	0..1
authenticator		Authenticator	0..\*
participant		Participant	0..\*
Act Relationships
inFulfillmentOf		In Erfüllung von, –noch nicht verwendet–	0..\*
documentationOf		Dokumentierte Gesundheitsdienstleistung, –noch nicht verwendet–	0..\*
relatedDocument		Bezug zu vorhergehenden Dokumenten	0..\*
authorization		Einverständniserklärung	0..\*
componentOf		Informationen zum Patientenkontakt	0..1
component		CDA Body	1..1

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

Bemerkungen zu Konformanz-Anforderungen beim CDA Arztbrief

Generelle Anforderungen an den Header

Für die Arztbriefe auf CDA Release 2 Basis werden die folgenden generellen Anforderungen an Header Elemente gestellt: Regel PERS: Jede Person muss durch einen Namen <name> identifiziert sein. Jede Person sollte zusätzlich Adresse <addr> und Telekommunikations-Informationen (telecom) aufweisen. Regel HCPC: Für jeden Heilberufler muss ein Name, eine Adresse und die Telekommunikations-Information angegeben werden. Dies geschieht über die „scoping organization" oder in der assoziierten Rolle, wo dies erlaubt ist. Wenn Adresse und Telekom-Kontakte nicht bekannt sind, muss dies über das @nullFlavor Attribut angezeigt werden. Regel ORGC: Jede Organisation muss durch einen Namen, eine Adresse und Telekommunikations-Information, optional auch über eine registrierte OID identifiziert sein. Bei Angabe einer OID haben die expliziten Angaben im Konfliktfall geringere Priorität.

Wenn name, addr und telecom Informationen vorhanden sein müssen, aber nicht bekannt sind, muss das @nullFlavor Attribut in den XML Instanzen genutzt werden. Gültige Werte sind hierbei:

Code	Bedeutung	Deutsche Bezeichnung
UNK	Unknown	Unbekannt
NASK	Not asked	Nicht erfragt
NAV	Temporarily unavailable	Zurzeit nicht verfügbar
ASKU	Asked but unknown	Erfragt, aber unbekannt

Tabelle 2: Vokabeldomäne (Auszug) für null flavors

Ein Beispiel:

<telecom nullFlavor="NASK"/>

Angegebene Telefonnummern Regel TURS: ...müssen das URI Schema „tel:", „fax:" oder „mailto:" aufweisen Regel TINT: ...müssen im Falle von internationalen Telefonnummern mit einem „+" beginnen Regel TCHS: ...dürfen nur Ziffernzeichen 0 bis 9 nutzen sowie als visuelle Separatorzeichen nur Bindestrich –, Punkte . oder Klammern ( ) verwenden.

Beispiele:

<telecom value="tel:(0221)467-1234.2"/>'''
<telecom value="fax:(02236)83-12323-12"/>'''
<telecom value="tel:+49.172.266.0814"/>'''

<telecom nullFlavor="NASK"/>

Spezielle Anforderungen an den Header

Regel HEAD: Der Header darf nur aus den in Tabelle 1 genannten Elementen bestehen. Andere Elemente sind nicht erlaubt.

templateID

Die Nutzung von templateID, einem XML Element, das an vielen Stellen im CDA Arztbrief vorkommen kann, ist optional. Zu einem späteren Zeitpunkt werden hier die Regeln genannt werden können, denen das ganze CDA Dokument oder Teile davon unterliegen müssen. Dies sind in der Regel Kardinalitäts- und Strukturforderungen oder auch zu erfüllende Erfordernisse in Bezug auf den Inhalt, Vokabularien etc. Vorübergehend können im Rahmen dieses Leitfadens die Konformanz-Anforderungen wie folgt spezifiziert werden:

<templateID extension="CDA-R2-AB100" root="1.2.276.0.76.3.1.13.10"/>

Allgemeine Hinweise zu den verwendeten HL7 Datentypen

Nähere Informationen zu Datentypen und deren Verwendung sind dem Datentypen und CMETs Leitfaden der HL7-Benutzergruppe in Deutschland e. V. \[dtcmetv3-hl7de\] zu entnehmen.

typeId-Element

Nach dem Root-Element ClinicalDocument muss das folgende, zurzeit konstante XML Element in einem CDA Release 2 Dokument enthalten sein.

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

Regel TYID: Die typeID is wie im obigen XML Fragment gezeigt anzugeben.

Dokumenten-Id

id Dokumenten-Id II \[1..1\] Die Dokumenten-Id eines Arztbriefs ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit eindeutig und für alle Zeit identifiziert. Ein CDA-Dokument hat genau eine Id. Identifikationen sind vom Typ Instance Identifier (siehe Datentypen). Das XML-Element id weist die XML Attribute @extension und @root auf. Regel IIRT: Das @root Attribut ist bei Instanzidentifikatoren verpflichtend anzugeben.

Im @root Attribut wird das Dokument-erzeugende Anwendungssystem identifiziert. Üblicherweise wird an diese Id noch eine Kennung des Anwendungssystems für Dokument-Ids angehängt. Im @extension Attribut wird die Dokumentennummer des Anwendungssystems angegeben. Im folgenden Beispiel hat das ein Dokument erzeugende Anwendungssystem die OID 2.16.840.1.113883.2.6.15.3.427. Dokumenten-Ids sind dadurch gekennzeichnet, dass eine .1 angehängt wird. Das System erzeugt eine interne Nummer für ein Dokument (13234453645), die im @extension Attribut zu finden ist. Zusammen mit dem @root Attribut entsteht so jeweils ein weltweit eindeutiger Instanzidentifikator.

<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>

Für die Kommunikation nach außen muss eine OID gewählt werden, die eindeutig für die Instanz des Anwendersystems ist. In der Regel werden diese OIDs vom Hersteller des jeweiligen Anwendersystems kommen, der seine tatsächlichen Installationen (Applikations-Instanzen) mit entsprechenden eindeutigen OIDs zu versehen hat. Das heißt, dass jede Installation eines Anbieters eine eindeutige OID besitzt und verwendet. Mandantenfähige Systeme müssen für jeden Mandanten eine eigene OID haben. Für weitere Informationen zur Vergabe und Verwendung von OIDs siehe auch die Ausführungen im Anhang Seite 140.

Typisierung des Dokuments

code Dokumententyp CE CWE \[1..1\] Über das code Modellattribut der ClinicalDocument Klasse wird eine Typisierung des Dokuments vorgenommen. In den hier vorliegenden Fällen ist eines der in der folgenden Tabelle aufgeführten „Discharge Summarization Notes" zu wählen.

Code	Dokumenten-Typ	Deutsche Bezeichnung	Berufsgruppe	Umgebung
34133-9	Summarization of Episode Note	Zusammenfassung der Behandlungsepisode	Heilberufler	Ambulante Versorgung
18842-5	Discharge summarization note	Zusammenfassung bei Entlassung	Heilberufler	Ambulante Versorgung
11490-0	Discharge summarization note	Zusammenfassung bei Entlassung	Arzt	Ambulante Versorgung
34745-0	Discharge summarization note	Zusammenfassung bei Entlassung	Pflege-dienst	Ambulante Versorgung
34105-7	Discharge summarization note	Zusammenfassung bei Entlassung	Heilberufler	Kranken¬haus
34106-5	Discharge summarization note	Zusammenfassung bei Entlassung	Arzt	Kranken¬haus
18761-7	Transfer summarization note	Zusammenfassung bei Verlegung	Heilberufler	Ambulante Versorgung
28616-1	Transfer summarization note	Zusammenfassung bei Verlegung	Arzt	Ambulante Versorgung
28651-8	Transfer summarization note	Zusammenfassung bei Verlegung	Pflege-dienst	Ambulante Versorgung
18733-6	Ambulatory visit note	Bericht über ambulanten Besuch
18742-7	Arthroscopy report	Athroskopischer Bericht
18743-5	Autopsy report	Autopsiebericht
18745-0	Cardiac catheterization report	Herzkatheterbericht
11488-4	Consultation note	Konsilbericht
18747-6	CT report	CT Bericht
11520-4	Echocardiogram report	EKG Befund
15507-7	Emergency visit note	Notfallbericht
11492-6	History and physical note	Anamnese und Befund
11504-8	Operative note	Operationsbericht
11505-5	Procedure note	Therapiebericht
11506-3	Progress note	Verlaufsbericht
11522-0	Radiology report	Röntgenbefund
11519-6	Social service report	Bericht des Sozialdienstes
11529-5	Surgical pathology report	Pathologischer Bericht
28616-1	Transfer summary (physician)	Verlegungsbrief	Arzt
28651-8	Transfer summary (nurse)	Verlegungsbrief	Pflege-dienst
11542-8	Visit note	Bericht über einen Patientenbesuch

Tabelle 3: Vokabeldomäne (Auszug) für ClinicalDocument.code

(OID: 2.16.840.1.113883.6.1 \[LOINC\]). Die Einrückungen in den Codes sollen eine Hierarchie andeuten, so kann die „Zusammenfassung der Behandlunsgepisode" als übergeordneter Begriff aller Zusammenfassungs-Dokumente gesehen werden.

Zur eindeutigen Identifikation der Typisierung wird das Codesystem LOINC (Logical Observation Identifiers Names and Codes \[LOINC\]) verwendet. Im XML @code Attribute steht der eigentliche Code, @codeSystem ist die OID des LOINC Systems (2.16.840.1.113883.6.1). Regel CDCD: Beim ClinicalDocument.code ist die Angabe von @code und @codeSystem verpflichtend. Regel CDLN: Als Codesystem für ClinicalDocument.code ist LOINC zu verwenden.

Der optionale @displayName kann die klartextliche Bedeutung wiedergeben, darf aber von der empfangenden Anwendung selbst nicht ausgewertet werden. Es ist zu beachten, dass eine Klassifikation des Inhalts in diesem Sinne in der Regel auch Inhaltsanforderungen vorgibt. So können Anwendungsszenarien für den Arztbrief dahin gehend definiert werden, dass bestimmte Teile darin vorkommen müssen, damit er „gültig" ist.

<code code="34105-7" codeSystem="2.16.840.1.113883.6.1"
      displayName="Zusammenfassung bei stationärer Entlassung"/>

Zusätzliche Dokumenttyp-Bezeichnung

title zusätzliche Dokumententyp-Bezeichnung ST \[0..1\]

Beim optionalen title können klartextlich zusätzliche Dokumententypbezeichnungen aufgenommen werden. Dabei kann der „Titel" auch den Dokumententyp, Autoren und das Datum enthalten.

<title>Wiesenhof Klinik Entlassbrief</title>

<title>Entlassbrief von Dr. Müller, Gutsklinik, vom 24.09.2005</title>

Erstellungsdatum des Dokuments

effectiveTime Erstellungsdatum des Dokuments TS \[1..1\]

Das verpflichtende Erstellungsdatum der Dokumentation (Dokument) wird in effectiveTime als Zeitpunkt wiedergegeben.

Regel CDET: Das Erstellungsdatum ClinicalDocument.effectiveTime muss mindestens tagesgenau sein, d. h. es muss mindestens ein Datum mit Jahr, Monat und Tag angegeben sein.

Die Angabe einer Zeitzone ist optional. Wenn möglich sollte auch Stunde und Minute mit angegeben werden, wenn diese für die Erstellung der medizinischen Dokumentation bekannt ist. Im Beispiel wurde das Dokument am 24.9.2005 um 16:34 Uhr erzeugt.

<effectiveTime value="200509241634"/>

Vertraulichkeit des Dokuments

confidentialityCode Vertraulichkeitsgrad CE CWE \[1..1\]

Hier wird der Vertraulichkeitsgrad des Dokuments codiert. Zugelassen sind folgende Codes

Code	Display Name	Deutsche Bezeichnung
N	normal	Normale Vertraulichkeitsregeln sind anzuwenden. Nur autorisiertes Personal darf auf die Daten zugreifen.
R	restricted	Eingeschränkter Zugriff, nur Personal in einer zeitnahen medizinischen Dienstleistungsfunktion darf auf die Daten zugreifen.
V	very restricted	Stark eingeschränkter Zugriff, Zugriffsregeln gibt der "Privacy Officer" des Daten-Anbieters vor.

Tabelle 4: Vokabel Domäne (Auszug) für ClinicalDocument.confidentiali¬tyCode (OID: 2.16.840.1.113883.5.25)

Im folgenden Beispiel sind normale Vertraulichkeitsmaßregeln für das Dokument gültig.

<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>

Sprache des Dokuments

languageCode Sprache des Dokuments CS CNE \[0..1\]

Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Kleinbuchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Großbuchstaben) festgelegt.

Regel CDLC: Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).

<languageCode code="de-DE"/>

Der languageCode ist ein Element des CDA-Headers, das den Sprachenkontext für das gesamte Dokument bestimmt, es sei denn, dies wird für bestimmte Inhalte, z. B. für einen anderssprachig verfassten Abschnitt, anders definiert.

Versionierung des Dokuments

setId Set-Kennung des Dokuments II \[0..1\]

versionNumber Versionsnummer INT \[0..1\]

Der CDA-Header repräsentiert ebenfalls die Beziehungen zu anderen Dokumenten mit Referenz auf die oben genannte Dokumenten-Identifikation. Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden. Entweder können beide Attribute fehlen, oder beide müssen anwesend sein. Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, die setId bleibt gleich.

<setId extension="D17" root="2.16.840.1.113883.3.933"/>
<versionNumber value="2"/>

Während ein Originalbericht neue eindeutige Werte für Clinical¬Document.id (verpflichtend) und setId sowie eine versionNumber von 1 aufweist (letztere beide optional im Orginalbericht), müssen Anhänge oder Ersetzungen von Vordokumenten jedenfalls diese zusätzlichen Angaben enthalten. Der Zusammenhang zwischen diesen Attributen wird weiter unten bei der Beschreibung der Dokumentenbeziehungen (Abschnitt 5.13) erläutert.

Die übrigen Attribute der Klasse ClinicalDocument werden nicht benutzt.

Teilnehmende Parteien (Participants)

Eine Zahl von so genannten „Teilnehmern" (Participants) wird ebenfalls im Header eines CDA Release 2 Dokuments spezifiziert. Diese sind im Kontext dieses Leitfadens

• der Patient (recordTarget)
• der Autor der Dokumentation (author)
• die das Dokument erstellende Organisation (custodian)
• beabsichtigte Empfänger des Dokuments (informationRecipient)
• der vor dem Gesetz verantwortliche Unterzeichner (legalAuthenticator)
• andere unterzeichnende Personen (authenticator)

Dies sind Beziehungen (relationships), die von der ClinicalDocument Klasse ausgehen.

Patient

PatientRole

Im CDA-Header muss mindestes eine Patientenrolle beschrieben sein, die genau von einer Person gespielt wird. Die recordTarget Beziehung weist auf die Patient-Klasse und gibt an, zu welchem Patienten dieses Dokument gehört. Regel PATR: Es ist mindestens eine Patientenrolle (role) mit genau einem Patienten (entity) anzugeben.

Abbildung 7: Klassen rund um den Patienten

Die PatientRole-Klasse weist folgende Attribute auf.

id Patienten-Identifikationsnummer SET<II> \[1..\*\]

Identifikationen sind vom Typ Instance Identifier (II). Im XML Attribut @extension wird die Id des Patienten selbst angegeben, während @root auf das die Identifikation ausgebende Anwendungssystem hinweist, das mittels Object Identifer (OID) beschrieben wird. Weitere Hinweise zu OIDs und zu den Identifikationen finden sich im Anhang. Die Patienten-Identifikation selbst ist als Set von IDs definiert, d.h. es können mehrere Identifikatoren für den Patienten angegeben werden. In diesem Kontext sollten dabei nur diejenigen IDs genannt werden, die das erzeugende System selbst als Patienten-ID benutzt, zum Beispiel lokale Nummern, die eGK Nummer etc. Im Beispiel hat der Patient eine von einem lokalen System (OID 2.16.840.1.113883.3.933) vergebene Id (6245), außerdem ist als zweite Id die eGK-Versichertennummer (OID 1.2.276.0.76.4.1) angegeben.

<id extension="6245" root="2.16.840.1.113883.3.933"/>
<id extension="1543627549" root="1.2.276.0.76.4.1"/>

addr Adresse SET<AD> \[0..\*\]

Die (optionalen) Adressen des Patienten werden in addr angegeben. Die Adressen werden von HL7 als rollen-bezogen betrachtet.

Im Beispiel ist der Patient zu Hause in der Dorfstraße 54 in 51371 Leverkusen.

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

telecom Telekommunikation-Kontakte SET<TEL> \[0..\*\]

Das Attribut telecom beinhaltet alle telekommunikationstechnisch möglichen Kontaktdaten des Patienten.

Das Beispiel zeigt eine Telefonnummer 0049 221 4765342 (internationale Schreibweise) und eine Emailadresse (dp@berlin.de)

<telecom value="tel:+49.221.4765342"/>
<telecom value="mailto:dp@berlin.de"/>

Patient (Entität)

Die Rolle des Patienten wird durch eine Person gespielt, die zugehörige Entität-Klasse ermöglicht weitere Attribute.

name Name des Patienten \[0..\*\]

	@	Attribut	DT	Card	Conf	Beschreibung
		name		0..*		Name des Patienten In diesem Attribut ist der Name des Patienten untergebracht.

	@	Attribut	DT	Card	Conf	Beschreibung
		administrativeGenderCode	CE CWE <= AdministrativeGender	0..1		Geschlecht

Das Geschlecht des Patienten ist codiert aus dem entsprechenden HL7 Vokabular anzugeben. So wie alle Codes wird im @code Attribut der jeweilige Code angegeben, in @codeSystem wird mittels OID auf das Code-System verwiesen, aus der dieser Code entnommen ist. Dies ist hier konstant 2.16.840.1.113883.5.1.

Lvl	Type, Domain name and/or Mnemonic code	Mnemonic	Print Name	Definition/Description
1	L: (F)	F	Female	Weiblich
1	L: (M)	M	Male	Männlich
1	L: (UN)	UN	Undifferentiated	Nicht bestimmbar (z. B. Hermaphrodite)

Tabelle 5: Vokabel Domäne für AdministrativeGender (OID 2.16.840.1.113883.5.1)

	@	Attribut	DT	Card	Conf	Beschreibung
		birthTime	TS	0..1		Geburtsdatum

Das Geburtsdatum ist anzugeben im @value Attribut des birthTime Elements im entsprechenden Datumsformat HL7 (yyyymmdd).

Heilberufler-Organisation für den Patienten

In der mit der PatientRole Klasse verbundenen providerOrganization providerOrganization \[0..1\] den Patienten betreuende Organisation wird die Heilberufler-Organisation angegeben (z. B. Krankenhaus, Hausarzt-Praxis), die den Patienten betreut. Hierbei sind eine ID, Name, Telekommunikationskontakte und Adressen vorgesehen.

	@	Attribut	DT	Card	Conf	Beschreibung
		id	II	0..*		ID der Heilberufler-Organisation

Identifikationen sind vom Typ Instance Identifier (siehe Datentypen). In dem XML Attribut @extension können die IDs der Heilberufler-Organisation selbst angegeben werden, während @root auf das Identifikationssystem hinweist (das in der Regel von einer entsprechenden Organisation/Instanz herausgegeben bzw. gepflegt wird). Beispielsweise haben die von der Sammel- und Vergabestelle Institutionskennzeichen (SVI) der Arbeitsgemeinschaft Institutionskennzeichen (IK) herausgegebenen Institutionskennzeichen die Root OID 1.2.276.0.76.4.5.

<id extension="175648374" root="1.2.276.0.76.4.5"/>

	@	Attribut	DT	Card	Conf	Beschreibung
		name	ON	0..*		Name der Heilberufler-Organisation

Der Name der Heilberufler-Organisation muss hier angegeben werden.

<name>Wohlsein Krankhaus</name>

	@	Attribut	DT	Card	Conf	Beschreibung
		telecom	TEL	0..*		Telekommunikation-Kontakte

Das (optionale) Attribut telecom beinhaltet alle bekannten Telekommunikationsdaten der Heilberufler-Organisation.

<telecom use="WP" value="tel:02412127070"/>
<telecom use="WP" value="fax:0241212707122"/>
<telecom use="WP" value="http://www.wohlsein-leverkusen.de"/>

	@	Attribut	DT	Card	Conf	Beschreibung
		addr	AD	0..*		Adresse der Heilberufler-Organisation

Die (optionalen) Adressen der Heilberufler-Organisation können in addr angegeben werden. Das Wohlsein Krankenhaus hat die Anschrift Krankenhausstr. 12, 51371 Leverkusen.

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

Das Beispiel zeigt Patient Paul Pappel (männlich), geb. 17.12.1955, mit zwei Identifikationsnummern (eine davon eine eGK-Versichtertennummer), wohnhaft in der Dorfstraße 54, 51371 Leverkusen und der Telefonnummer 0221/4445678.

<recordTarget>
    <!--- Patienten-Daten -->
    <patientRole>
      <id extension="6245" root="2.16.840.1.113883.3.933"/>
      <id extension="1543627549" root="1.2.276.0.76.4.1"/>
      <addr>
        <streetName>Dorfstraße</streetName>
        <houseNumber>54</houseNumber>
        <postalCode>51371</postalCode>
        <city>Leverkusen</city>
      </addr>
      <telecom value="tel:0221.444.5678"/>
      <patient>
        <name>
          <given>Paul</given>
          <family>Pappel</family>
        </name>
        <administrativeGenderCode code="M"
               codeSystem="2.16.840.1.113883.5.1"/>
        <birthTime value="19551217"/>
      </patient>
      <providerOrganization>
        <telecom use="WP" value="tel:02412127070"/>
        <telecom use="WP" value="fax:0241212707122"/>
        <addr>
          <streetName>Krankenhausstraße</streetName>
          <houseNumber>12</houseNumber>
          <postalCode>51371</postalCode>
          <city>Leverkusen</city>
        </addr>
      </providerOrganization>
    </patientRole>
</recordTarget>

Geburtsort des Patienten

Es kann sinnvoll sein, den Geburtsort des Patienten anzugeben. Dies wird in der Klasse BirthPlace und Andeutung einer Lokation (Place) mit optionalem Namen und Adresse (oder Teilen davon) bewerkstelligt.

Abbildung 8: Birthplace und Place Klasse des Patienten birthPlace \[0..1\] Geburtsort-Informationen des Patienten

Dabei muss genau eine Lokation in der Place Klasse beschrieben sein, die die folgenden Attribute aufweist.

	@	Attribut	DT	Card	Conf	Beschreibung
		name	EN	0..1		Name des Geburtsorts

	@	Attribut	DT	Card	Conf	Beschreibung
		addr	AD	0..1		Adressinformationen zum Geburtsort

Regel BRCC: Die Angabe eine Adresse mit mindestens city oder country beim Geburtsort ist verpflichtend. Im folgenden Beispiel ist der Geburtsort des Patienten Paul Pappel mit Sassnitz angegeben.

<patient>
  <name>
    <given>Paul</given>
    <family>Pappel</family>
  </name>
  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
  <birthTime value="19551217"/>
  <birthplace>
    <place>
      <addr>
        <city>Saßnitz</city>
      </addr>
    </place>
  </birthplace>
</patient>

Sprachfertigkeiten des Patienten

	<	Element	DT	Card	Conf	Beschreibung
		languageCommunication		0..*		Diese Klasse gibt die Sprachfertigkeiten des Patienten wieder.

Vormundschaft für den Patienten (Guardian)

	<	Element	DT	Card	Conf	Beschreibung
		Guardian		0..*		In der Klasse Guardian kann über Vormundschaften für den Patienten Auskunft gegeben werden.

Autor

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

Abbildung 9: Klassen rund um den Autor

functionCode Funktion des Autors CE CWE \[0..1\] <= ParticipationType

In der author-Partizipation wird ein functionCode angegeben, der aus der Vokabel-Domäne ParticipationType kommt. Hier ist zu beachten, dass ggf. auch im ClinicalDocument.code Hinweise auf die Funktion des Autors gegeben werden können, z. B. „Verlaufsdokument (Student)" das von einem Medizinstudenten angelegt wurde.

time Zeitpunkt der Dokumentation (Autorenschaft) TS \[1..1\]

Im verpflichtend anzugebenden time Attribut wird der Zeitpunkt der Doku¬mentation angegeben. Informationen über den Autor werden in der AssignedAuthor Klasse ange¬geben. Hier finden sich die üblichen Angaben zur Identifikation, Adresse und zu Telekommunikationsangaben.

id ID des Autors SET<II> \[1..\*\]

Eine ID für den Autor ist verpflichtend anzugeben. Es können mehrere IDs genannt werden.

<id extension="190388km89" root="2.16.840.1.113883.3.24535"/>

addr Adresse SET<AD> \[0..\*\]

Optionale Adressen des Autors.

telecom Telekommunikation-Kontakt SET<TEL> \[0..\*\]

Optionale Telekommunikationskontakte des Autors. Von der Autor-Klasse gehen zwei Typen von Assoziationen aus, representedOrganization und assignedPerson bzw. assignedDevice. assignedPerson \[0..1\] Assoziation mit Autor als Person representedOrganization \[0..1\] Assoziation mit Organisation des Autors

Autor als Person

Der Autor eines Dokuments kann sowohl eine lebende Person als auch ein Gerät wie z.B. ein Laboranalysegerät sein. Die Rolle Autor wird gespielt von der (optionalen) assignedPerson, wenn es sich beim Autor um eine Person handelt. Diese ermöglicht wiederum durch Angabe des Namens der Person eine nähere Spezifizierung des Autors.

name Name(n) des Autors SET<PN> \[0..\*\]

Geräte als Autoren

Ist der Autor ein Gerät, das Daten geliefert hat, wird die Autoren-Rolle von einer assignedDevice gespielt. Ein Gerät als Autor ist in diesem Kommunikationsszenario nicht vorgesehen.

Durch den Autor repräsentierte Organisation

Dies stellt die optionale Assoziation mit der AssociatedEntity Klasse dar. In der representedOrganization Klasse kann die Organisation näher bezeichnet werden, die der Autor repräsentiert, d. h. in der Regel die Organisation, in der die Dokumentation erstellt wurde.

id ID der Organisation II \[0..\*\] name Name der Organisation ON \[0..\*\] telecom Telekommunikation-Kontakte TEL \[0..\*\] addr Adresse der Organisation AD \[0..\*\]

Beispiel: Dr. med. Theo Phyllin ist der Autor eines CDA-Dokuments, das er am 29. September 2005 abgeschlossen hat. Er repräsentiert dabei das Wohlsein Krankenhaus.

<author> <assignedAuthor> <id extension="190388km89" root="2.16.840.1.113883.3.24535"/> <assignedPerson> <name> <prefix qualifier="AC">Dr. med.</prefix> <given>Theo</given> <family>Phyllin</family> </name> </assignedPerson> <representedOrganization> <name>Wohlsein Krankenhaus</name> <telecom use="WP" value="tel:0242127070"/> <telecom use="WP" value="fax:024212707122"/> <addr> <streetName>Krankenhausstraße</streetName> <houseNumber>240</houseNumber> <postalCode>51371</postalCode> <city>Leverkusen</city> </addr> </representedOrganization> </assignedAuthor> </author>

Verwaltende Organisation

Die Organisation (custodian), die für die Verwaltung des Dokuments verantwortlich ist, muss verpflichtend in der entsprechenden Klasse wiedergegeben werden.

Abbildung 10: Klassen rund um die das Dokument verwaltende Organisation (CustodianOrganization)

id ID der Organisation SET<II> \[1..\*\] Die Organisation muss mindestens mit einer ID gekennzeichnet werden. Name der verwaltenden Organisation, Telekommunikations-Kontakte und Adresse sind optional. name Name der Organisation ON \[0..1\] telecom Telekommunikation-Kontakte TEL \[0..1\] addr Adresse der Organisation AD \[0..1\]

<custodian> <assignedCustodian> <representedCustodianOrganization> <id extension="175648374" root="1.2.276.0.76.4.5"> <telecom use="WP" value="tel:0242127070"/> <addr> <streetName>Krankenhausstraße</streetName> <houseNumber>240</houseNumber> <postalCode>51371</postalCode> <city>Leverkusen</city> </addr> </representedCustodianOrganization> </assignedCustodian> </custodian>

Beabsichtigte Empfänger des Dokuments

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 mögliche 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).

Abbildung 11: Klassen rund um die beabsichtigten Empfänger des Dokuments

typeCode Typ des Empfängers Im @typeCode der Participation kann angegeben werden, ob es sich um einen primären Empfänger handelt (default) oder im einen sekundären Empfänger („CC Kopie"). Die zugelassenen Werte für den @typeCode sind:

Code	Display Name	Deutsche Bezeichnung
PRCP	(primary recipient) \[default\]	Empfänger, der primär das Dokument empfängt.
TRC	secondary recipient	Ein Empfänger, der ebenfalls (sekundär) das Dokument erhält („CC Kopie")

Tabelle 6: Vokabel Domäne für InformationRecipientRole

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. Beispiel: Dr. med. Kai Heitmann ist ein primärer Empfänger und erhält den Arztbrief.

<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:0247365746"/> <addr> <streetAddress>Mühlenweg 1a</streetAddress> <houseNumber>1a</houseNumber> <postalCode>52152</postalCode> <city>Simmerath</city> </addr> </receivedOrganization> </intendedRecipient> </informationRecipient>

Unterzeichner

Dokumente können den Unterzeichner beinhalten. Dabei gibt es höchstens einen Unterzeichner, der vor dem Gesetz verantwortlich ist (legalAuthenticator) und optional mehrere andere unterzeichnende Personen (authenticator). Die beiden die Beziehung repräsentierenden Klassen zum Dokument enthalten folgende Attribute.

time Zeitpunkt der Unterschrift TS \[1..1\] Im verpflichtend anzugebenden time Attribut wird der Zeitpunkt der Unterschrift angegeben. signatureCode Typisierung der Unterschrift CS CNE \[1..1\] Hier wird eine Typisierung der Signatur angegeben. Die zulässigen Werte sind in der folgenden Tabelle wiedergegeben.

Code	Display Name	Deutsche Bezeichnung
I	Intended	Es ist beabsichtigt, eine Signatur anzubringen
S	Signed	Signatur ist vorhanden, entweder auf Papier niedergelegt oder digital (DSig)
R	Required	Eine Signatur ist erforderlich

Tabelle 7: Vokabel Domäne für ParticipationSignature

Abbildung 12: Klassen um authenticator/ legalAuthenticator

Die Klasse AssignedEntity umfasst Informationen über die Unterzeichner und weist die folgenden Attribute auf.

id ID des Unterzeichners SET<II> \[1..\*\] Eine ID für den Unterzeichner ist verpflichtend anzugeben. Es können mehrere IDs genannt werden. addr Adresse des Unterzeichners SET<AD> \[0..\*\] Optionale Adressen des Unterzeichners. telecom Telekommunikation-Kontakte SET<TEL> \[0..\*\] Optionale Telekommunikationskontakte des Unterzeichners.

Unterzeichner als Person

Die Rolle des Unterzeichners wird gespielt von der verpflichtend anzugebenden assignedPerson. Diese ermöglicht wiederum durch Angabe des Namens der Person eine nähere Spezifizierung des Unterzeichners. name Name(n) des Unterzeichner SET<PN> \[0..\*\]

Personen bei der Dateneingabe (dataEnterer)

In der Assoziation dataEnterer können Personen spezifiziert werden, die bei der Dateneingabe beteiligt waren, wie die Sekretärin u.a. Diese Information wird in diesem Leitfaden zunächst nicht verwendet.

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, Versicherungs¬träger sowie weitere in Beziehung zum Patienten stehende Parteien genannt werden.

Abbildung 13 Klassen rund um weitere Beteiligte (participants)

Participant

Die Beziehungsklasse participant zum Dokument kann 0 bis mehrere Male vorkommen und enthält die folgenden Attribute.

typeCode Typisierung der Beteiligung CS \[1..1\] <= ParticipationType Der @typeCode gestattet die Typisierung der Beteiligung an der Dokumentation. Hier sind in diesem Kontext zwei Werte, IND und HLD, zugelassen (siehe Tabelle weiter unten).

Code	Bedeutung
IND	(indirect target) sind nicht notwendigerweise direkt an der Dokumentation beteiligt oder werden durch die Aktivitäten beeinflusst, haben aber eine indirekte Beziehung dazu, wie zum Beispiel Angehörige.
HLD	(holder) zeigt an, dass der Beteiligte im Besitz von Dokumenten wie z. B. Verträgen (Versicherungspolice, Kostenübernahmeerklärung etc.) ist, die eine Übereinkunft mit dem Autor repräsentieren.
COV	(coverage target) zeigt die Beteiligung des Individuums an einer Versicherung an, entweder als Besitzer der Versicherungspolice oder einem Versicherten, der unter diese Versicherung fällt.

Tabelle 8: Vokabel Domäne ParticipationType

functionCode Funktion der Beteiligten Person/Organisation CE CWE \[0..1\] <= ParticipationFunction Dieser Code wird benutzt, um die exakte Funktion zu beschreiben, die ein Beteiligter im Dokumentationszusammenhang bei der Gesundheitsdienstleistung hat. FunctionCode wird in diesem Leitfaden nicht genutzt.

time Zeitpunkt/-raum der Beteiligung IVL<TS> \[0..1\] Im Allgemeinen ist der Zeitpunkt/-raum der Beteiligung optional. Wenn dieser angegeben ist, sagt er etwas zur Zeitspanne aus, innerhalb die Beteiligung stattgefunden hat. Zum Beispiel würde bei einem Versicherten der Zeitraum der Versicherung angegeben.

associatedEntity \[0..1\] Assoziation Dies stellt die optionale Assoziation mit der AssociatedEntity Klasse dar.

AssociatedEntity

Die Klasse AssociatedEntity weist die folgenden Attribute auf.

id Identifikation des Beteiligten SET<II> \[0..\*\]

Hier kann die Identifikation des Beteiligten im zugehörigen Kontext angegeben werden.

classCode Klassifizierung der Beteiligung CE CWE \[0..1\] <= RoleClassAssociative

Im @classCode wird eine Klassifizierung der Beteiligung vorgenommen.

Beschreibung	type Code	Associated Entity. classCode	Vokabeldomäne für AssociatedEntity. code	Anmerkungen
Angehöriger	IND	NOK	PersonalRelationship RoleType	Person muss angegeben sein
Notfall-Kontakt	IND	ECON	PersonalRelationship RoleType	Person muss angegeben sein
Besitzer (Halter) einer Versicherungs¬police	HLD	POLHOLD		Die Organisation muss genannt sein
Versicherter	COV	COVPTY
Andere unterstützend mitwirkende Personen oder Organisationen	IND	PRS	PersonalRelationship RoleType||Person muss angegeben sein

Tabelle 9: Vokabel Domänen für AssociatedEntity.classCode

Daraus leiten sich auch die folgenden Regeln ab, participatingEntity ist hierbei als Synonym für die assoziierte Rolle gewählt. Regel PTNO: Wenn der participation.typeCode IND und participatingEntity.classCode NOK ist, dann muss mindestens eine Person angegeben werden. Regel PTEC: Wenn der participation.typeCode IND und participatingEntity.classCode ECON ist, dann muss mindestens eine Person angegeben werden. Regel PTPH: Wenn der participation.typeCode HLD und participatingEntity.classCode POLHOLD ist, dann muss mindestens eine Organisation angegeben werden. Regel PTPR: Wenn der participation.typeCode IND und participatingEntity.classCode PRS ist, dann muss mindestens eine Person angegeben werden.

Bei der Vokabeldomäne PersonalRelationshipRoleType muss einer der in folgender Tabelle genannten Codes benutzt werden.

	RoleCode – PersonalRelationshipRoleType (OID 2.16.840.1.113883.5.111)
Lvl	Type, Domain name and/or Mnemonic code	Mnemonic	Print Name	Definition/Description	Deutsche Beschreibung
1	A: PersonalRelationshipRoleType
2	_ S: FamilyRelationshipRoleType (FAMMEMB)	FAMMEMB	Family Member	A relationship between two people characterizing their "familial" relationship	Familiäre Beziehung zweier Menschen.
3	_ _ S: Child (CHILD)	CHILD	Child	The player of the role is a child of the scoping entity.	Der Rolleninhaber ist ein Kind der Zielperson.
4	_ _ _ S: AdoptedChild (CHLDADOPT)	CHLDADOPT	adopted child	The player of the role is a child taken into a family through legal means and raised by the scoping person (parent) as his or her own child.	Der Rolleninhaber ist ein Kind, welches rechtlich in die Familie aufgenommen wurde und von der Zielperson wie ein eigenes aufgezogen wird.
5	_ _ _ _ L: _(DAUADOPT)	DAUADOPT	adopted daughter	The player of the role is a female child taken into a family through legal means and raised by the scoping person (parent) as his or her own child.	Der Rolleninhaber ist ein weibliches Kind, welches rechtlich in die Familie aufgenommen wurde und von der Zielperson wie ein eigenes aufgezogen wird.
5	_ _ _ _ L: _(SONADOPT)	SONADOPT	adopted son	The player of the role is a male child taken into a family through legal means and raised by the scoping person (parent) as his or her own child.	Der Rolleninhaber ist ein männliches Kind, welches rechtlich in die Familie aufgenommen wurde und von der Zielperson wie ein eigenes aufgezogen wird.
4	_ _ _ S: ChildInLaw (CHLDINLAW)	CHLDINLAW	child in-law	The player of the role is the spouse of scoping person\’s child.	Der Rolleninhaber ist der Ehegatte des Kindes der Zielperson
5	_ _ _ _ L: _(DAUINLAW)	DAUINLAW	daughter in-law	The player of the role is the wife of scoping person\’s son.	Der Rolleninhaber ist die Ehefrau des Kindes der Zielperson
5	_ _ _ _ L: _(SONINLAW)	SONINLAW	son in-law	The player of the role is the husband of scoping person\’s daughter.	Der Rolleninhaber ist der Ehemann des Kindes der Zielperson
4	_ _ _ S: FosterChild (CHLDFOST)	CHLDFOST	foster child	The player of the role is a child receiving parental care and nurture from the scoping person (parent) but not related to him or her through legal or blood ties.	Der Rolleninhaber ist ein Pflegekind, welches elterliches Fürsorge von der Zielperson erhält, aber nicht mit ihr in rechtlicher oder Blutsverwandtschaft steht.
5	_ _ _ _ L: _(DAUFOST)	DAUFOST	foster daughter	The player of the role is a female child receiving parental care and nurture from the scoping person (parent) but not related to him or her through legal or blood ties.	Der Rolleninhaber ist ein weibliches Pflegekind, welches elterliche Fürsorge von der Zielperson erhält, aber nicht mit ihr in rechtlicher oder Blutsverwandtschaft steht.
5	_ _ _ _ L: _(SONFOST)	SONFOST	foster son	The player of the role is a male child receiving parental care and nurture from the scoping person (parent) but not related to him or her through legal or blood ties.	Der Rolleninhaber ist ein männliches Pflegekind, welches elterliche Fürsorge von der Zielperson erhält, aber nicht mit ihr in rechtlicher oder Blutsverwandtschaft steht.
4	_ _ _ S: NaturalChild (NCHILD)	NCHILD	natural child	The player of the role is an offspring of the scoping entity as determined by birth.	Der Rolleninhaber ist ein blutsverwandter, selbstgeborener Nachkomme der Zielperson
5	_ _ _ _ L: _(DAU)	DAU	natural daughter	The player of the role is a female offspring of the scoping entity (parent).	Der Rolleninhaber ist ein weiblicher, blutsverwandter, selbstgeborener Nachkomme der Zielperson
5	_ _ _ _ L: _(SON)	SON	natural son	The player of the role is a male offspring of the scoping entity (parent).	Der Rolleninhaber ist ein männlicher, blutsverwandter, selbstgeborener Nachkomme der Zielperson
4	_ _ _ S: StepChild (STPCHLD)	STPCHLD	step child	The player of the role is a child of the scoping person\’s spouse by a previous union.	Der Rolleninhaber ist ein Kind des Ehegatten der Zielperson, welches einer vorherigen Beziehung entstammt.
5	_ _ _ _ L: _(STPDAU)	STPDAU	stepdaughter	The player of the role is a daughter of the scoping person\’s spouse by a previous union.	Der Rolleninhaber ist ein weibliches Kind des Ehegatten der Zielperson, welches einer vorherigen Beziehung entstammt.
5	_ _ _ _ L: _(STPSON)	STPSON	stepson	The player of the role is a son of the scoping person\’s spouse by a previous union.	Der Rolleninhaber ist ein männliches Kind des Ehegatten der Zielperson, welches einer vorherigen Beziehung entstammt.
3	_ _ S: GrandChild (GRNDCHILD)	GRNDCHILD	grandchild	The player of the role is a child of the scoping person\’s son or daughter.	Der Rolleninhaber ist ein Kind des Sohnes oder der Tochter der Zielperson
4	_ _ _ L: _(GRNDDAU)	GRNDDAU	granddaughter	The player of the role is a daughter of the scoping person\’s son or daughter.	Der Rolleninhaber ist eine Tochter des Sohnes oder der Tochter der Zielperson
4	_ _ _ L: _(GRNDSON)	GRNDSON	grandson	The player of the role is a son of the scoping person\’s son or daughter.	Der Rolleninhaber ist ein Sohn des Sohnes oder der Tochter der Zielperson
3	_ _ S: Grandparent (GRPRN)	GRPRN	Grandparent	The player of the role is a parent of the scoping person\’s mother or father.	Der Rolleninhaber ist ein Elternteil der Mutter oder des Vaters der Zielperson.
4	_ _ _ L: _(GRFTH)	GRFTH	Grandfather	The player of the role is the father of the scoping person\’s mother or father.	Der Rolleninhaber ist der Vater der Mutter oder des Vaters der Zielperson.
4	_ _ _ L: _(GRMTH)	GRMTH	Grandmother	The player of the role is the mother of the scoping person\’s mother or father.	Der Rolleninhaber ist die Mutter der Mutter oder des Vaters der Zielperson.
3	_ _ S: GreatGrandparent (GGRPRN)	GGRPRN	great grandparent	The player of the role is a parent of the scoping person\’s grandparent.	Der Rolleninhaber ist ein Elternteil der Großmutter oder des Großvaters der Zielperson.
4	_ _ _ L: _(GGRFTH)	GGRFTH	great grandfather	The player of the role is the father of the scoping person\’s grandparent.	Der Rolleninhaber ist der Vater der Großmutter oder des Großvaters der Zielperson.
4	_ _ _ L: _(GGRMTH)	GGRMTH	great grandmother	The player of the role is the mother of the scoping person\’s grandparent.	Der Rolleninhaber ist die Mutter der Großmutter oder des Großvaters der Zielperson.
3	_ _ S: NieceNephew (NIENEPH)	NIENEPH	niece/nephew	The player of the role is a child of scoping person\’s brother or sister or of the brother or sister of the scoping person\’s spouse.	Der Rolleninhaber ist ein Kind des Bruders oder der Schwester der Zielperson oder des Bruders oder der Schwester des Ehegatten der Zielperson.
4	_ _ _ L: _(NEPHEW)	NEPHEW	nephew	The player of the role is a son of the scoping person\’s brother or sister or of the brother or sister of the scoping person\’s spouse.	Der Rolleninhaber ist ein Sohn des Bruders oder der Schwester der Zielperson oder des Bruders oder der Schwester des Ehegatten der Zielperson.
4	_ _ _ L: _(NIECE)	NIECE	niece	The player of the role is a daughter of the scoping person\’s brother or sister or of the brother or sister of the scoping person\’s spouse.	Der Rolleninhaber ist eine Tochter des Bruders oder der Schwester der Zielperson oder des Bruders oder der Schwester des Ehegatten der Zielperson.
3	_ _ S: Parent (PRN)	PRN	Parent	The player of the role is one who begets, gives birth to, or nurtures and raises the scoping entity (child).	Der Rolleninhaber ist diejenige Person, die die Zielperson geboren hat, oder diese nährt und aufzieht.
4	_ _ _ S: NaturalParent (NPRN)	NPRN	natural parent
5	_ _ _ _ L: _(NFTH)	NFTH	natural father	The player of the role is a male who begets the scoping entity (child).	Der Rolleninhaber ist eine männliche Person, die die Zielperson (kind) gezeugt hat.
5	_ _ _ _ L: _(NMTH)	NMTH	natural mother	The player of the role is a female who conceives or gives birth to the scoping entity (child).	Der Rolleninhaber ist eine weibliche Person, die die Zielperson (Kind) empfangen und geboren hat.
4	_ _ _ S: ParentInLaw (PRNINLAW)	PRNINLAW	parent in-law	The player of the role is the parent of scoping person\’s husband or wife.	Der Rolleninhaber ist ein Elternteil des Ehegatten der Zielperson.
5	_ _ _ _ L: _(FTHINLAW)	FTHINLAW	father-in-law	The player of the role is the father of the scoping person\’s husband or wife.	Der Rolleninhaber ist der Vater des Ehegatten der Zielperson.
5	_ _ _ _ L: _(MTHINLOAW)	MTHINLOAW	mother-in-law	The player of the role is the mother of the scoping person\’s husband or wife.	Der Rolleninhaber ist die Mutter des Ehegatten der Zielperson.
4	_ _ _ S: StepParent (STPPRN)	STPPRN	step parent	The player of the role is the spouse of the scoping person\’s parent and not the scoping person\’s natural parent.	Der Rolleninhaber ist der Ehegatte eines Elternteils der Zielperson, aber kein natürlicher Elternteil der Zielperson.
5	_ _ _ _ L: _(STPFTH)	STPFTH	stepfather	The player of the role is the husband of scoping person\’s mother and not the scoping person\’s natural father.	Der Rolleninhaber ist der Ehemann der Mutter der Zielperson, aber nicht der natürliche Vater der Zielperson.
5	_ _ _ _ L: _(STPMTH)	STPMTH	stepmother	The player of the role is the wife of scoping person\’s father and not the scoping person\’s natural mother.	Der Rolleninhaber ist die Ehefrau des Vaters der Zielperson, aber nicht die natürliche Mutter der Zielperson.
4	_ _ _ L: _(FTH)	FTH	Father	The player of the role is a male who begets or raises or nurtures the scoping entity (child).	Der Rolleninhaber ist eine männliche Person, die die Zielperson gezeugt hat, oder diese nährt und aufzieht.
4	_ _ _ L: _(MTH)	MTH	Mother	The player of the role is a female who conceives, gives birth to, or raises and nurtures the scoping entity (child).	Der Rolleninhaber ist eine weibliche Person, die die Zielperson empfangen oder geboren hat, oder diese nährt und aufzieht.
3	_ _ S: Sibling (SIB)	SIB	Sibling	The player of the role shares one or both parents in common with the scoping entity.	Der Rolleninhaber teilt ein Elternteil oder beide Eltern mit der Zielperson.
4	_ _ _ S: HalfSibling (HSIB)	HSIB	half-sibling	The player of the role is related to the scoping entity by sharing only one biological parent.	Der Rolleninhaber hat mit der Zielperson nur einen biologischen Elternteil gemeinsam.
5	_ _ _ _ L: _(HBRO)	HBRO	half-brother	The player of the role is a male related to the scoping entity by sharing only one biological parent.	Der Rolleninhaber ist eine männliche Person, die mit der Zielperson nur einen biologischen Elternteil gemeinsam hat.
5	_ _ _ _ L: _(HSIS)	HSIS	half-sister	The player of the role is a female related to the scoping entity by sharing only one biological parent.	Der Rolleninhaber ist eine weibliche Person, die mit der Zielperson nur einen biologischen Elternteil gemeinsam hat.
4	_ _ _ S: NaturalSibling (NSIB)	NSIB	natural sibling	The player of the role has both biological parents in common with the scoping entity.	Der Rolleninhaber hat mit der Zielperson beide biologischen Elternteile gemeinsam.
5	_ _ _ _ L: _(NBRO)	NBRO	natural brother	The player of the role is a male having the same biological parents as the scoping entity.	Der Rolleninhaber ist eine männliche Person, die mit der Zielperson beide biologischen Elternteile gemeinsam hat.
5	_ _ _ _ L: _(NSIS)	NSIS	natural sister	The player of the role is a female having the same biological parents as the scoping entity.	Der Rolleninhaber ist eine weibliche Person, die mit der Zielperson beide biologischen Elternteile gemeinsam hat.
4	_ _ _ S: SiblingInLaw (SIBINLAW)	SIBINLAW	sibling in-law	The player of the role is: (1) a sibling of the scoping person\’s spouse, or (2) the spouse of the scoping person\’s sibling, or (3) the spouse of a sibling of the scoping person\’s spouse.	Der Rolleinhaber ist (1) ein Geschwisterteil des Ehegatten der Zielperson (2) der Ehegatte eines Geschwisterteils der Zielperson (3) der Ehegatte eines Geschwisterteils des Ehegatten der Zielperson.
5	_ _ _ _ L: _(BROINLAW)	BROINLAW	brother-in-law	The player of the role is: (1) a brother of the scoping person\’s spouse, or (2) the husband of the scoping person\’s sister, or (3) the husband of a sister of the scoping person\’s spouse.	Der Rolleinhaber ist (1) ein Bruder des Ehegatten der Zielperson (2) der Ehemann einer Schwester der Zielperson (3) der Ehemann einer Schwester des Ehegatten der Zielperson.
5	_ _ _ _ L: _(SISLINLAW)	SISLINLAW	sister-in-law	The player of the role is: (1) a sister of the scoping person\’s spouse, or (2) the wife of the scoping person\’s brother, or (3) the wife of a brother of the scoping person\’s spouse.	Der Rolleinhaber ist (1) eine Schwester des Ehegatten der Zielperson (2) die Ehefrau eines Bruders der Zielperson (3) die Ehefrau eines Bruders des Ehegatten der Zielperson.
4	_ _ _ S: StepSibling (STPSIB)	STPSIB	step sibling	The player of the role is a child of the scoping person\’s stepparent.	Der Rolleninhaber ist ein Kind eines Stiefelternteils der Zielperson.
5	_ _ _ _ L: _(STPBRO)	STPBRO	stepbrother	The player of the role is a son of the scoping person\’s stepparent.	Der Rolleninhaber ist ein Sohn eines Stiefelternteils der Zielperson.
5	_ _ _ _ L: _(STPSIS)	STPSIS	stepsister	The player of the role is a daughter of the scoping person\’s stepparent.	Der Rolleninhaber ist eine Tochter eines Stiefelternteils der Zielperson.
4	_ _ _ L: _(BRO)	BRO	Brother	The player of the role is a male sharing one or both parents in common with the scoping entity.	Der Rolleninhaber ist eine männliche Person, die mit der Zielperson beide Elternteile gemeinsam hat.
4	_ _ _ L: _(SIS)	SIS	Sister	The player of the role is a female sharing one or both parents in common with the scoping entity.	Der Rolleninhaber ist eine weibliche Person, die mit der Zielperson beide Elternteile gemeinsam hat.
3	_ _ S: SignificantOtherRoleType (SIGOTHR)	SIGOTHR	significant other	A person who is important to one\’s well being; especially a spouse or one in a similar relationship. (The player is the one who is important)	Eine Person, die für das eigene Wohlergehen wichtig ist, vor allem der Ehegatte oder Lebensgefährte. (Der Rolleninhaber ist die wichtige Person)
4	_ _ _ S: Spouse (SPS)	SPS	spouse	The player of the role is a marriage partner of the scoping person.	Der Rolleninhaber ist der Ehegatte der Zielperson.
5	_ _ _ _ L: _(HUSB)	HUSB	husband	The player of the role is a man joined to a woman (scoping person) in marriage.	Der Rolleninhaber ist ein Mann, der einer Frau (Zielperson) als Ehepartner verbunden ist.
5	_ _ _ _ L: _(WIFE)	WIFE	wife	The player of the role is a woman joined to a man (scoping person) in marriage.	Der Rolleninhaber ist eine Frau, die einem Mann (Zielperson) als Ehepartner verbunden ist.
3	_ _ L: _(AUNT)	AUNT	aunt	The player of the role is a sister of the scoping person\’s mother or father.	Der Rolleninhaber ist eine Schwester der Mutter oder des Vaters der Zielperson.
3	_ _ L: _(COUSN)	COUSN	cousin	The player of the role is a relative of the scoping person descended from a common ancestor, such as a grandparent, by two or more steps in a diverging line.	Der Rolleninhaber ist ein Verwandter mindestens zweiten Grades der Zielperson, der von einem gemeinsamen Vorfahren wie Z.B einem gemeinsamen Großelternteil abstammt.
3	_ _ L: _(DOMPART)	DOMPART	domestic partner	The player of the role cohabits with the scoping person but is not the scoping person\’s spouse.	Der Rolleninhaber lebt räumlich mit der Zielperson zusammen ist aber nicht deren Ehegatte.
3	_ _ L: _(ROOM)	ROOM	Roomate	One who shares living quarters with the subject.	Jemand der ein Zimmer mit jemandem teilt.
3	_ _ L: _(UNCLE)	UNCLE	uncle	The player of the role is a brother of the scoping person\’s mother or father.	Der Rolleninhaber ist ein Bruder der Mutter oder des Vaters der Zielperson.
2	_ L: _(FRND)	FRND	unrelated friend	The player of the role is a person who is known, liked, and trusted by the scoping person.	Der Rolleninhaber ist eine Person, die die Zielperson kennt, mag und der sie vertraut.
2	_ L: _(NBOR)	NBOR	neighbor	The player of the role lives near or next to the scoping person.	Der Rolleninhaber lebt neben oder in der Nähe der Zielperson.

Tabelle 10: Codes für PersonalRelationshipRoleType (OID 2.16.840.1.113883.5.1095)

Telekommunikations-Kontakte und Adresse der beteiligten Person bzw. Organisation sollten angegeben werden. Regel PTTL: Mindestens eine Kontaktinformation, telecom oder addr, muss bei einer beteiligten Person vorliegen.

telecom Telekommunikation-Kontakte TEL \[0..\*\]

addr Adresse der beteiligten Entität AD \[0..\*\] Beispiel, Angabe eines Notfall-Kontakts (Person-Angabe verpflichtend).

<participant typeCode="IND">
  <associatedEntity classCode="ECON">
    <code code="DOMPART" codeSystem="2.16.840.1.113883.5.1095"/>
    <addr>
      <streetName>Große Rurstraße</streetName>
      <houseNumber>38</houseNumber>
      <postalCode>52428</postalCode>
      <city>Jülich</city>
    </addr>
    <telecom use="MC" value="tel:0172.1234567"/>
    <associatedPerson>
      <name>
        <given>Florian</given>
        <family>Gattano</family>
      </name>
    </associatedPerson>
  </associatedEntity>
</participant>

Versichertendaten

Wie im vorangegangen Abschnitt gezeigt, sind über die participation Beziehung im Dokument Angaben zur Versicherung möglich. Diese Angaben sind nicht zu Abrechnungszwecken im Dokument enthalten, sondern rein informativ. Dabei ist über die participation und AssociatedEntity Klasse die Organisation zu nennen, die die Kosten übernimmt bzw. als Versicherungsgeber fungiert. Will man mehrere Versicherungsverhältnisse andeuten, so sind mehrere participation Beziehungen anzugeben. Weitere Erläuterungen zu den Klassen finden sich in Abschnitt 5.12.7 „Weitere Beteiligte". Beispiel: Der Patient ist „familien"-versichert (dargestellt im associatedEntity.classCode), Anschrift und Angaben zur versicherten Person (associatedPerson) werden gemacht, ebenso Angaben zum Versicherungsunternehmen (scopingOrganization).

<participant typeCode="HLD">
  <!-- time wird in der Regel  nur angegeben, wenn die Versicherungskarte vorlag und dessen
            Gültigkeitsangaben bekannt sind; dann ist in <low> das Einlesedatum der Karte und
            in <high> das „gültig bis" Datum anzugeben -->
  <time>
    <low value="20050101"/>
    <high value="20051231" inclusive="true"/>
  </time>
  <associatedEntity classCode="POLHOLD">
    <!-- Hier ist die Versicherten-ID benannt -->
    <id extension="12-254-4569/9" root="2.16.840.1.113883.2.6.234.93345"/>
    <!-- falls sich der Patient in Abhängigkeit von einer Familienversicherung befindet 
         muss dies hier so angedeutet werden -->
    <code code="FAMDEP" codeSystem="2.16.840.1.113883.5.1095"/>
    <!-- falls der Patient selbst der Versicherte ist, wäre dies:
               <code code="SELF" codeSystem="2.16.840.1.113883.5.111"/>
         -->
    <!-- Anschrift Versicherungsnehmer -->
    <addr>
      <streetName>Große Rurstraße</streetName>
      <houseNumber>38</houseNumber>
      <postalCode>52428</postalCode>
      <city>Jülich</city>
    </addr>
        <!-- Versicherungsnehmer -->
    <associatedPerson>
      <name>
        <given>Florian</given>
        <family>Gattano</family>
      </name>
    </associatedPerson>
    <!-- Informationen zum Versicherungunternehmen-->
    <scopingOrganization>
      <id extension="93345" root="2.16.840.1.113883.2.6.234"/>
      <name>Wohlkouvert Versicherungsgesellschaft</name>
      <addr>
        <streetName>Versicherungsgasse</streetName>
        <houseNumber>69</houseNumber>
        <postalCode>52401</postalCode>
        <city>Jülich</city>
      </addr>
    </scopingOrganization>
  </associatedEntity>
</participant>

Bezug zu vorgehenden Dokumenten

Der Bezug zu vorgehenden Dokumenten der gleichen Dokumentenklasse wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert. Ein Anhang an ein klinisches Dokument ist selbst ein Originaldokument. Der Bezug zum Vordokument, auf das sich der Anhang bezieht, wird über die parentDocument Beziehung ausgedrückt, in dem der dazugehörige @typeCode den Wert „APND" (append) erhält. Der Originalbericht, an den der Anhang angefügt wird, bleibt dabei unverändert.

Abbildung 14: Clinical Document und Parent Document Klasse

Regel RELD: Ein konformes CDA Dokument kann ein einzelnes relatedDocument mit @typeCode APND, oder ein relatedDocument mit @typeCode RPLC, oder ein relatedDocument mit @typeCode XFRM, oder zwei relatedDocuments mit @typeCode XFRM und RPLC, oder zwei relatedDocuments mit @typeCode XFRM und APND enthalten.

Wurde bereits ein Dokument versendet und soll es durch ein neues „ersetzt" werden, wird zukünftig ausschließlich das neue „Ersatz-Dokument" anstelle des Originalberichts verwendet und kommuniziert. Es erhält ebenso eine neue eindeutige ClinicalDocument.id, allerdings benutzt das neue Dokument dieselbe setId wie der Originalbericht, und die versionNumber wird um 1 erhöht. Der Originalbericht ist dadurch zwar im Sinne des Dokumentenmanagement ersetzt, bleibt aber aus Gründen der Nachvollziehbarkeit einer Dokumentenhistorie im System vorhanden. Der Bezug zum Vordokument, auf das sich der Ersatz bezieht, wird über die parentDocument ausgedrückt, in dem die dazugehörige @typeCode den Wert „RPLC" (replace) erhält. Schließlich gibt es noch den Bezug „XFRM" – Transformation, das Ergebnis eines Transformationsprozesses, d.h. das Dokument ist aus einem anderen Originaldokument hervorgegangen. Dies wird im Rahmen dieses Leitfadens zunächst nicht verwendet. Die folgende Tabelle gibt Aufschluss über die möglichen Werte der @typeCodes in der relatedDocument Beziehung.

Code	Display Name	Deutsche Bezeichnung
APND	appends	Ein Nachtrag ist ein Anhang zu einem existierenden Bericht, der ergänzende Informationen enthält. Der Anhang ist selbst ein ursprünglicher Bericht, der sich auf den Hauptbericht bezieht. Der Hauptbericht, welcher den Anhang erhalten soll, bleibt im Inhalt und Status unverändert
RPLC	replaces	Ein Ersatzbericht ersetzt einen existierenden Bericht. Der Status des zu ersetzenden Berichtes wird auf "überholt" gesetzt, der ursprüngliche Bericht bleibt in der Regel aber noch im System als historische Referenz verfügbar.
XFRM	transformed	Im Rahmen dieses Leitfadens zunächst nicht verwendet. Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Tabelle 11: Vokabel Domäne for relatedDocument.typeCode

Der Zusammenhang zwischen ClinicalDocument.id, ClinicalDocument.setId und ClinicalDocument.versionNumber bei den verschiedenen Dokumentbeziehungen wird in der folgenden Darstellung verdeutlicht. Jedes Dokument, ob Nachtrag, Ersatzbericht oder Transformation, ist ein eigenständiges Dokument mit jeweils einer eigenen eindeutigen ClinicalDocument.id. Bei einem Replacement sind die ClinicalDocument.setId gleich. Das initiale Dokument beginnt mit der ClinicalDocument.versionNumber 1. Jedes neue Ersatzdokument erhöht den Zähler um 1. Bei einem Nachtrag sind die ClinicalDocument.setId verschieden und ClinicalDocument.versionNumber immer 1, da es sich bei Nachträgen ob Originaldokumente handelt.

Abbildung 15: Zusammenhang zwischen ClinicalDocument.id, ClinicalDocument.setId und ClinicalDocument.versionNumber bei den verschiedenen Dokumentbeziehungen Regel PDID: In der anhängenden Klasse ParentDocument ist zumindest die id verpflichtend anzugeben, die das „Vater"-Dokument eindeutig referenziert.

<relatedDocument typeCode="APND">
    <parentDocument>
      <id extension="463957847" root="1.2.276.0.58"/>
    </parentDocument>
</relatedDocument>

Informationen zum Patientenkontakt (Encompassing Encounter)

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, muss die Information in dieser Klasse mitgegeben werden, inklusive der Dauer des Aufenthalts (hier: nicht nur stationäre Aufenthalte, sondern auch Patientenkontakt in der Praxis eines Niedergelassenen beispielsweise) und der Einrichtung, wo der Patientenaufenthalt stattfand.

Abbildung 16: EncompassingEncounter Klasse und Umgebung

EncompassingEncounter

In der EncompassingEncounter Klasse, die höchstens einmal genannt werden kann, werden der Aufenthalt klassifiziert und Zeitangaben gemacht.

code Klassifikation des Aufenthaltes CE CWE \[0..1\] <= ActEncounterCode

Dieser Code wird benutzt, um den Aufenthalt zu klassifizieren. Hier sind momentan die folgenden Codes zu verwenden.

Code	Display Name	Deutsche Bezeichnung
IMP	Inpatient encounter	Stationärer Aufenthalt
AMB	Ambulatory	Ambulanter Aufenthalt
VR	Virtual	Kontakt ohne tatsächliche Begegnung der Personen vor Ort (z. B. Telefongespräch).

Tabelle 12: Vokabel Domäne for EncompassingEncounter.code

effectiveTime Zeitraum des Aufenthaltes IVL<TS> \[1..1\]

Die verpflichtende Aufenthaltsperiode wird im effectiveTime Attribut angegeben. Dies ist in der Regel ein Zeitintervall. Im Beispiel hatte der Patient vom 1. bis einschließlich 10. November 2005 einen stationären Aufenthalt in der Wohlmichgut Klinik.

<componentOf>
  <encompassingEncounter>
    <code code="IMP" codeSystem="2.16.840.1.113883.5.4"/>
    <effectiveTime>
      <low value="20051101"/>
      <high value="20051110" inclusive="true"/>
    </effectiveTime>
    <location>
      <healthCareFacility>
        <serviceProviderOrganization>
          <name>Wohlmichgut Klinik</name>
          <addr>
            <streetName>Sundstraße</streetName>
            <houseNumber>4</houseNumber>
            <postalCode>50389</postalCode>
            <city>Wesseling</city>
          </addr>
        </serviceProviderOrganization>
      </healthCareFacility>
    </location>
  </encompassingEncounter>
</componentOf>

Einverständniserklärung (authorization)

In dieser optionalen Klasse können die Einverständniserklärungen reflektiert werden, die mit dem Dokument verbunden sind. Dies kann ein Einverständnis für einen Eingriff oder die Verfügungbarmachung der Informationen gegenüber Dritten beinhalten. Der Typ der Einverständiserklärung wird dabei in Concent.code angegeben.

Abbildung 17: Consent Klasse Einverständiserklärungen, auf die im CDA Header Bezug genommen wird, sind abgeschlossen, haben also immer den statusCode completed on sollten hinterlegt sein.

id Identifikation der Einverständniserklärung SET<II> \[0..\*\]

Hier kann die Identifikation der Einverständiserklärung angegeben werden.

code Typ der Einverständniserklärung CE CWE \[0..1\]

Der Typ der Einverständiserklärung, z. B. ein OPS-Code.

statusCode Statuscode <= completed

Der statusCode einer Einverständiserklärung ist immer completed, da es sich immer um eine abgeschlossene Einverständiserklärung handelt. Im folgenden Beispiel wird die Einverständniserklärung für eine diagnostische Behandlung (typisiert mittel eines OPS Codes) dokumentiert und identifiziert.

<authorization>
    <consent>
      <id extension="cs856727-298784" root="1.2.276.0.76.3645.239"/>
      <code code="3-00d" codeSystem="1.2.276.0.76.5.310"/>
      <statusCode code="completed"/>
    </consent>
</authorization>

Dokumentierte Gesundheitsdienstleistung (documentation Of)

Mit der Assoziation documentationOf wird die eigentliche Gesundheitsdienstleistung repräsentiert, z. B. eine Koloskopie oder Appendektomie. Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument.code wiedergegeben ist. Die Behandlung selbst war eine Koloskopie. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen. In ServiceEvent.effectiveTime kann der Zeitpunkt/Zeitraum der Gesundheitsdienstleistung angegeben werden, im Gegensatz zum Encounter, der diese „umrahmt". Diese Information wird in diesem Leitfaden zunächst nicht verwendet.

CDA R2 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 aus einem structuredBody Element, das wiederum section Elemente aufweist, mit denen die Information strukturiert werden kann. Die Möglichkeit, hier „nonXMLBody"-Elemente unterzubringen, wird nicht unterstützt. Danach zeichnet sich für den Arztbrief folgende Grobstruktur ab.

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

Allgemeiner Aufbau des Body

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 „Level 1 bis 3 unten) besteht. Regel BDSC: Ein Clinical Document muss mindestens ein „section"-Element enthalten. Regel SCTX: Jede Sektion muss genau ein „Text"-Element enthalten, das nicht leer sein darf.

Section.text Text des Abschnitts ED \[0..1\]

Abbildung 18: Section-Klasse mit ihren Attributen. Sections können auch Subsections (als Komponente) enthalten, also ineinander geschachtelt sein.

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, dass sich wiederum untergliedern könnte in „Eigenanamnese", „Familienanamnese", „Sozialanamnese" sowie „bisherige Operationen", „bisherige Impfungen" etc. In der Regel sind die Abschnitte mit Codes versehen (siehe unten). Manche Abschnitte sind mit zusätzlichen Einträgen (Komponenten) versehen, die RIM-Klassen entsprechen und hochstrukturierte Codierungen zulassen. Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.

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

Abbildung 19: Ü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.

Level 1 bis Level 3

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

Section.title Titel des Abschnitts ST \[0..1\]

Das section Element enthält demzufolge nur einen optionalen Titel sowie den verpflichtend anzugebenden Text, der die narrative Ausführung der klinischen Dokumentation darstellt.

Im Level 2 werden die Abschnitte klassifiziert. Die Identifikation dieser Abschnitte ist auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird erreicht durch die Assoziation des Abschnitts mit einem Code. Hierfür werden in diesem Leitfaden ausschließlich LOINC Codes zur Dokumentenabschnittsklassifizierung verwendet.

Section.code Klassifizierung des Abschnitts CE CWE \[0..1\]

Das section Element erhält dabei ein code Element, das den Inhalt des Abschnitts klassifiziert. Im 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.

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 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. Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z. B. ein OP-Bericht. 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.

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 Anwendunginteroperabilität.

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

Abbildung 20: Eine section Komponente besteht aus einem <code\>, der den Abschnitt typisiert, sowie einer Überschrift im \<title\>. Im obligato¬rischen <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 (siehe dazu auch „Zusammenhang zwischen Text und Entry, Seite 102)

XML technisch gesprochen validieren CDA Dokumente jeden Levels 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. Zu dem Abschnitt kann auch eine Sprache gewählt werden, wenn diese von der für das ganze Dokument (mittels languageCode im Header, siehe dort) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements languageCode des Headers.

Section.languageCode Sprache des Abschnitts CS CNE \[0..1\]

Klassifizierung der Sektionen mittels LOINC Codes

Mit den einzelnen Sektionen werden die „allgemeinen" Kategorien einer medizinischen Dokumentation strukturiert. Auf Level 2 erhalten diese Sektionen LOINC Codes. Tabelle 1 zeigt die LOINC der Sektionen.

Kategorie		Code	Bezeichnung	LOINC Bezeichnung	Kardinalität
Anamnese
		11348-0	bisherige Krankheiten	HISTORY OF PAST ILLNESS	Optional
		10157-6	Krankheiten in der Familie	HISTORY OF FAMILY MEMBER DISEASES	Optional
		29762-2	Sozial-Anamnese	SOCIAL HISTORY	Optional
		11369-6	Frühere Impfungen, Impfstatus	HISTORY OF IMMUNIZATIONS	Optional
		10167-5	bisherige Operationen / Eingriffe	HISTORY OF SURGICAL PROCEDURES	Optional
		11346-4	Frühere ambulante Besuche	HISTORY OF OUTPATIENT VISITS	Optional
		11336-5	bisherige Krankenhaus-Aufenthalte	HISTORY OF HOSPITALIZATIONS	Optional
		11322-5	bisheriger allgemeiner Gesundheitszustand	HISTORY OF GENERAL HEALTH	Optional
		10165-9	Anamnese psychiatrischer Symptome und Krankheiten	HISTORY OF PSYCHIATRIC SYMPTOMS & DISEASES	Optional
		10158-4	Bisheriger Funktionsstatus in Bezug auf Selbstver¬sorgung und Aktivitäten des täglichen Lebens	HISTORY OF FUNCTIONAL STATUS	Optional
		11493-4	Information für Studien und Reports bei Entlassung	HOSPITAL DISCHARGE STUDIES SUMMARY	Optional
		11449-6	Status der Schwangerschaft	PREGNANCY STATUS	Optional
Allergien und Adverse Reactions
		10155-0	Allergie-Anamnese	HISTORY OF ALLERGIES	Optional
		11382-9	Allergische Reaktionen auf Medikamente	MEDICATION ALLERGY
Beschwerden/Leiden
		11450-4	Liste der Probleme	PROBLEM LIST	Optional
Diagnosen
		11535-2	Diagnose bei Entlassung aus dem Krankenhaus (Text)	HOSPITAL DISCHARGE DX:NAR	Optional
		8651-2	Diagnose bei Entlassung aus dem Krankenhaus (Code)	HOSPITAL DISCHARGE DX	Optional
		8646-2	Diagnose bei Aufnahme ins Krankenhaus (Code)	HOSPITAL ADMISSION DX	Optional
		29548-5	Diagnose (Text)	DIAGNOSIS:NAR	Optional
		29308-4	Diagnose (Codiert)	DIAGNOSIS:NOM	Optional
Medikation
		10160-0	Medikamenten-Anamnese	HISTORY OF MEDICATION USE	Optional
		10183-2	Medikamente bei Entlassung aus dem Krankenhaus	HOSPITAL DISCHARGE MEDICATIONS	Optional
		19009-0	Jetzige Medikation	MEDICATION.CURRENT	Optional
Krankenhausaufenthalt
		8648-8	Verlauf im Krankenhaus	HOSPITAL COURSE	Optional
		29299-5	Grund des Besuchs	REASON FOR VISIT	Optional
		10154-3	Hauptbeschwerden	CHIEF COMPLAINT	Optional
		42349-1	Grund für die Überweisung/Einweisung	REASON FOR REFERRAL	Optional
		42348-3		ADVANCE DIRECTIVES	Optional
		10164-2	Jetzige Anamnese	HISTORY OF PRESENT ILLNESS	Optional
		10210-3	Allgemeinzustand, Befunde körperliche Untersuchung	GENERAL STATUS, PHYSICAL FINDINGS	Optional
		10184-0	Allgemeinzustand bei Entlassung aus dem Krankenhaus	HOSPITAL DISCHARGE PHYSICAL	Optional
		8716-3	Vitalparameter, körperliche Untersuchung	VITAL SIGNS, PHYSICAL FINDINGS	Optional
Plan
		18776-5	Behandlungsplan, weiteres Vorgehen	TREATMENT PLAN	Optional
Sonstiges
		11329-0	Allgemeine Anamnese	HISTORY GENERAL	Optional
		29554-3	Maßnahmen, Behandlungen, Prozeduren	PROCEDURE	Optional
weitere Section-Identifikationen (ohne LOINC Code)
		X-SALUT	Anrede	SALUTATIONS	Optional

Tabelle 13: LOINC Codes für Sektionen

Regel SCLN: Im Arztbrief sind nur LOINC Codes (OID des @codeSystem 2.16.840.1.113883.6.1) als primäre Klassifikation der Sections zugelassen. Alternative Codes können als <translation> angegeben werden.

Im Beispiel wird eine Section primär über den LOINC Code klassifiziert, eine alternative Codierung ist über <translation> Elemente zulässig.

<code code="10164-2" 
      codeSystem="2.16.840.1.113883.6.1">
  <translation code="XYZ" codeSystem="1.2.3.4.5.6.7.8"/>
</code>

Für den Fall, dass eine primäre LOINC Klassifikation noch nicht bekannt ist, dennoch aber ein Code (zum Beispiel ein lokaler Code) angegeben werden soll, darf dieser alternative Code nicht als Primärcode verwendet werden. Dort stehen nur LOINC Codes. Sollen Alternativen angegeben werden ohne einen primären LOINC Code, ist im Code Element nullFlavor zu benutzen, der alternative Code steht dann in der <translation>. Im Beispiel fehlt für eine Section primär der LOINC Code. Trotzdem soll ein lokaler Code die Section klassifizieren. Dazu wird der Primärecode mit nullFlavor angegeben, die alternative Codierung ist über <translation> Elemente berwerkstelligt.

<code nullFlavor="NA">
  <translation code="XYZ" codeSystem="1.2.3.4.5.6.7.8"/>
</code>

Die Kardinalität von Sections (optional, verpflichtend, konditional) ist von Anwendungsfall zu Anwendungsfall verschieden, also kontextbezogen. Die im Kontext „Arztbrief" definierten Kardinalitäten sind in der oben stehen¬den Tabelle aufgeführt und hier alle „optional". Hinweis: Für ein (zukünftiges) bestimmtes Anwendungsszenario kann als Regel aufgestellt werden, dass Entlassbriefe immer (mindestens) eine Diagnose enthalten müssen, die auch in Level 3 codiert ist.

Die Sections können nach Bedarf auch ineinander geschachtelt sein (Un¬ter¬abschnitte). In der folgenden Tabelle ist eine mögliche hierarchische Strukturierung wiedergegeben. In der Regel wird in heutigen Arztbriefen allerdings nur eine flache oder sehr begrenzt substrukturierte Form gewählt.

* Anrede Fragestellung Anamnese Eigenanamnese allgemeine Anamnese Frühere Krankheiten Frühere Operationen fachspezifische Anamnese (z. B. gynäkologische, urologische Anamnese,... psychosoziale Anamnese Familienanamnese Fremdanamnese Immunisierungen Schwangerschaften Medizinische Untersuchung klinische (körperliche) Untersuchung apparative Untersuchung Befund Fremdbefund spezifische, einige erfasste Befunde der einzelnen Fachgruppen z.B. Laborwerte Histologie Biopsie Radiologie Pathologie Kardiologie Entlassbefund Diagnosen mit ICD Code Fremddiagnose Auftragsdiagnose Aufnahmediagnose Verdachtsdiagnose Entlassdiagnose Abrechnungsdiagnose Cave zu beachtende wichtige Hinweise zum Patienten Allergien Risiken Therapie (therapeutische Maßnahmen) Medikamente fachspezifische Eingriffe, z.B. Operationen Strahlentherapie Lichttherapie psychiatrische Eingriffe weiteres (therapeutisches) Vorgehen Notiz Epikrise Zusammenfassender Rückblick Empfehlung Prognose Anhänge: Referenzen auf externe Dokumente Schlusstext

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.

<component>
  <structuredBody>
  ... 
    <component>
      <section>
        <code code=... codeSystem=... />
        <title> ... </title>
        <text>
           ...
        </text>
      </section>
    </component>
    ...
  </structuredBody>
</component>

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 strukturieren. 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).

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.

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.

Superskripts und Subskripts

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

Zeilenumbrüche

Das br Element
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. Patient kommt damit gut zurecht. </text>

Fußnoten

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

Referenz zu Multimedia-Inhalten

Es ist möglich, zusätzlich zu dem Text auch Referenzen auf externe Multimediaobjekte wie Bilder etc. zu spezifizieren. Dies geschieht über das renderMultiMedia Element und dient dazu aufzuzeigen, wo das Multimedia-Objekt gezeigt/dargestellt werden soll. Das renderMultiMedia Element hat ein optionales caption Element. Es weist außerdem die Referenz (XML ID) zum erforderlichen Objekt auf, die als XML IDREF im selben Dokument definiert sein muss. XML ID und IDREF sind also korrespondierende Definitionen (einmalig) und Referenzen darauf (mehrfach möglich) eines CDA Entry ObservationMedia (oder RegionOfInterest) im selben Dokument. Das renderMultiMedia Element trägt dabei im @referencedObject Attribut die ID. Die Information zum eigentlichen Objekt wird in einem CDA Entry festgehalten. Für diesen Leitfaden wird ausschließlich das Element observationMedia verwendet. Dieser Eintrag trägt im entry Element unter anderem das @ID Attribut als Zielreferenz des @referencedObject Attributs vom renderMultiMedia Element.

ObservationMedia Klasse

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

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

id Identifikation des Multimedia-Objekts SET<II> \[0..\*\] languageCode Sprachinformation

Der languageCode ist hier zunächst nicht zu verwenden.

value Nähere Spezifikation des Multimedia-Objekts ED \[1..1\]

Hier muss das eigentliche Objekt genannt werden.

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

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. Mit „verpflichtend" sind die Typen genannt, die durch Anwendungssysteme unterstützt werden müssen.

Tabelle mediaType Attribut Werte (Datenarten):
Code	Name	Status	Definition
text/plain	Plain Text	verpflichtend	Für beliebige Texte. Dies ist der \’default\’ Typ. In dieser Form ist er identisch mit dem ST Type.
text/html	HTML Text	empfohlen	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.
audio/basic	Basic Audio	verpflichtend	1- Kanal Audioformat für Sprache. Obwohl Unterstützung dieses Formats verpflichtend ist, wird es in den Niederlanden kaum benutzt werden.
audio/mpeg	MPEG audio layer 3	verpflichtend	MPEG-1 Audio layer-3 (auch bekannt als MP3) ist momentan der Standard für komprimierte Audiodaten.
image/png	PNG Image	verpflichtend	Portable Network Graphics (PNG) \[1] ist eine verlustfreie Komprimierung von Bilddateien. Wo vorher GIF benutzt wurde, muss jetzt PNG unterstützt werden.
image/jpeg	JPEG Image	verpflichtend	Dieses Format wird benutzt für hohe Resolutionen 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.
video/mpeg	MPEG Video	verpflichtend	MPEG ist ein internationaler Standard für Videobilder. Er ist weit verbreitet und Open-Source-Implementierungen sind verfügbar.

Tabelle 14: Zugelassene mediaTypes

Das darin enthaltene 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> <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" ID="MM1"> <id root="2.16.840.1.113883.19.2.1"/> <value xsi:type="ED" mediaType="image/jpeg"> <reference value="left_hand_image.jpeg"/> </value> </observationMedia> </entry> </section>

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.

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

Tabelle 15: 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>

Strukturen in Level 3

Es wird angestrebt, Level 3 Darstellungen schrittweise einzuführen. Das bedeutet, dass neben der obligatorischen Repräsentation der medizinischen Inhalte auf Level 2 auch optional die zusätzliche Darstellung dieser Inhalte auf Level 3 verwendet werden kann, um sie für das empfangende System strukturiert auswertbar zu machen. Es sei an dieser Stelle nochmals darauf hingewiesen, dass der Text in Level 1 bzw. 2 führend für den medizinsichen Inhalt ist, und dass Level 3 konstrukte dieselbe (aber maschinenauswertbare) Information tragen. Generell sind in der CDA Entry Auswahl folgende Klassen aus dem RIM modelliert.

CDA Entry	Bedeutung
Observation	Allgemeine oder spezifische Beobachtung, wie z. B. Diagnosen, Befunde, Laborergebnisse etc.
ObservationMedia	Medieninformation zur Beobachtung, z. B. externe Referenzen auf Bilder etc.
Procedure	Prozeduren, Eingriffe, die den Patienten „verändern"
RegionOfInterest	Fokusinformation
SubstanceAdministration	Verordnung von Medikamenten, Hilfsmitteln etc.
Supply	Verabreichung, Verfügbarmachung von Medikamenten, Hilfsmitteln etc.
Encounter	Kontakt mit Patient
Act	Generische Aktivität
Organizer	Ordnungsmöglichkeit für CDA Entries

Tabelle 16: CDA Entry Klassen

Zusammenhang Text und Entry

Die folgende Übersicht zeigt das Muster für Level 3. Zusätzlich zum Text folgt ein Entry Element, das die aus der Clinical Statement Choice genommenen Klassen nennt. Diese können auch miteinander verbunden bzw. hierarchisch ineinander geschachtelt werden.

<component> <structuredBody> ... <component> <section> <title> ... </title> <text> ... </text> <entry> <observation> oder andere Klassen </observation> </entry> </section> </component> <component> <section> <text> ... </text> <entry> ... </entry> </section> </component> <component> <section> ... </section> </component> </structuredBody> </component>

In diesem Leitfaden ist spezifiziert, dass bestimmte Informationskategorien (Diagnosen, Prozeduren) auf Level 3 darstellbar sind.

Referenzierung mit URIs

Elemente innerhalb des Textabschnittes (<text>) nutzen die ID Attribute, um die zugehörigen Level 3 Entries zu referenzieren. Dies stellt eine Ver¬knüpfung dar zwischen dem codierten Eintrag und dem Text. Dabei wird das Ziel verfolgt, schrittweise mehr strukturiertes Markup zur Verfügung zu stellen, das Applikationen nutzen können. Außerdem werden dadurch Doppeleinträge von Informationen verhindert. Jedes Element im narrativen Kontext kann ein ID Attribut mitführen. Dies ist vom Typ xs:ID und muss im gesamten Dokument eindeutig sein. IDs dieser Art beginnen mit einem Buchstaben, gefolgt von einem oder meh¬reren Buchstaben, Zahlen, Bindestrichen oder Unterstrichen.

||<code ... <originalText> <reference value="\#aaa"/> </originalText>...<code ... <originalText> <reference value="\#bbb"/> </originalText> ...

Gebrauch einer ID	Referenz einer ID
<list> <item ID="iii">List item 1</item> </list>||<code ... <originalText> <reference value="\#iii"/> </originalText> ...
Tabellenzelle 1	Tabellenzelle 2
<paragraph ID="pp-1"> Text </paragraph>||<originalText> <reference value="\#pp-1"/> </originalText>
<content ID="cc-1">Text 1</content>	...<reference value="\#cc-1"/>
<paragraph ID="pp-2">Ein Stück <content ID="cc-2">Text 2</content></paragraph>	...<reference value="\#pp-2"/> ...<reference value="\#cc-2"/>

Dies erlaubt, dass der Text mit einer einfachen URI dereferenziert werden kann. Die URI ist lokal im Dokument definiert, beginnt mit einem \#-Zeichen, gefolgt von der ID. Aus den obigen Beispielen würden die folgenden Textfragmente durch De-Referenzierung gewonnen.

ID Referenz	dereferenzierter Text
\#iii	List item 1
\#aaa	Tabellenzelle 1Tabellenzelle 2
\#bbb	Tabellenzelle 1
\#pp-1	Text
\#cc-1	Text 1
\#pp-2	Ein Stück Text 2
\#cc-2	Text 2

Bezug des Quelltexts zu den Entries

Der Bezug vom Quelltext zu den Entries wird im @typeCode Attribut des Entry Elements angegeben und ist im Normalfall (und Default) COMP (component). Dies ist der allgemeine Fall und bedeutet, dass die Information in den Entries im Inhalt des Quelltexts enthalten ist. Weiter sind keine inhaltlichen Implikationen dabei vorhanden. In diesem Falle ist außerdem der narrative Quelltext der authentifizierte Inhalt. CDA Entries können durch verschiedene Methoden abgeleitet werden, z. B. durch Verarbeitung der natürlichen Sprache, einer Person, die den Eintrag codiert, einem Werkzeug, das sowohl codierte Einträge als auch Text produziert. Die jeweilige Methode kann durch die participantRole unter Angabe der Person oder des benutzten Algorithmus identifiziert werden.

Abbildung 22: Ähnlich wie bei einzelnen Sections können auch jedem Entry einzeln Participants zugeordnet werden. So kann eine bestimmte Prozedur ergänzt werden um teilnehmende Personen, die nur an dieser Prozedur beteiligt waren.

Bezug zwischen Entries

Verbindungen zwischen verschiedenen Entries werden spezifiziert durch Angabe dieser Beziehung in entryRelationship. Beispiele für solche Beziehungen zwischen Entries sind:

• Observation und ObservationMedia (entryReleationship.typeCode = COMP „component")
• Observation („Nesselsucht") und Observation („Allergie"), entryReleationship.typeCode = MFST („Manifestation of")
• Eine Beobachtung besteht aus Teilbeobachtungen, z. B. eine Batterie von Labortests, systolischer und diastolischer Blutdruck.

Abbildung 23: Über die entryRelationship Klasse können die verschiedenen Entries miteinander verbunden werden. Der @typeCode gibt dabei die Art der Beziehung wieder.

Weiterhin gibt es Situationen, in denen Entries vorhanden sind, ohne dass dazu ein Quelltext vorhanden ist, z. B. bei Kalibierungsangaben, Reagenzien oder andere Informationen, die für die weitere Verarbeitung notwendig sind. Auch hier ist der @typeCode der entryRelationship = COMP. Für den Fall, dass der narrative Text gänzlich aus codierten Entries abgeleitet ist, wird dies mit dem @typeCode DRIV (derived from) angedeutet. Dies ist beispielsweise der Fall bei Diagnoseninformationen, die eigentlich vollständig hoch-codiert in den Entries vorliegen und woraus der klinische Text erzeugt wird. Auch ein Mix aus verschiedenen Entries und verschiedenen Beziehungstypen ist möglich.

Beschreibung der Abschnitte

Anrede

Dieser Abschnitt enthält die allgemeinen einleitenden Informationen eines Arztbriefes. Sie werden in einer Komponente zusammengefasst. Es handelt sich dabei um die Einleitungsfloskel (z. B. „Sehr geehrter Herr Kollege,...") und einer ersten Nennung des Patienten evtl. mit der zusätzlichen Angabe des Geburtsdatums.

<component> <section> <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> </component>

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

Fragestellung

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.

<component> <section> <title>Grund der Überweisung</title> <text>Röntgen Thorax in zwei Ebenen</text> </section> </component>

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

Anamnese

Dieser Abschnitt enthält die Anamnese-Informationen. Die Anamnese kann in die folgenden Kategorien aufgeteilt werden:

Angaben flach (ohne Substrukturen)

Angaben strukturiert

Eigenanamnese Allgemeine Anamnese Frühere Krankheiten Frühere Operationen Fachspezifische Anamnese Psychosoziale Anamnese Familienanamnese Fremdanamnese Immunisierungen Medikamentenanamnese Schwangerschaften||* Eigenanamnese Allgemeine Anamnese Frühere Krankheiten Frühere Operationen Fachspezifische Anamnese Psychosoziale Anamnese Familienanamnese Fremdanamnese Immunisierungen Medikamentenanamnese Schwangerschaften

Tabelle 17: Darstellung der Informationen zur Anamnese in flacher oder substrukturierter Form, die Codes für die jeweiligen Abschnitte sind hier weggelassen. In der Praxis findet sich in der Regel bislang allein die flache Wiedergabe der Informationen. Der Arztbrief in dieser Spezifikation lässt eine Angabe der verschiedenen „Sub"-Kategorien flach oder in hierarchischer Anordnung zu. Beides ist möglich. In der Praxis findet sich heutzutage noch meist die flache Struktur. Allerdings sind auch komplexere Dokumentationen vorhanden (die zunächst nicht Gegenstand dieser Spezifikation sind), wie zum Beispiel die Herzkatheder-Untersuchungsdokumentation die höher strukturiert (geschachtelt) ist.

Die dazugehörigen LOINC-Codes sind in Tabelle 13: LOINC Codes für Sektionen aufgeführt.

<component> <section> <title>Anamnese</title> <text> Sei Jahren wiederholt chronische Bronchitiden besonders bei kalter Luft. Bei Anstrengung exspiratorische Atemnot. Kontakt mit Haustieren. </text> </section> </component>

Befunde

Dieser Abschnitt enthält die Befund-Informationen. Es wird zunächst von einer Level-2 Darstellung ausgegangen. Eine Befundung kann in die folgenden Kategorien aufgeteilt werden:

Angaben flach (ohne Substrukturen)	Angaben strukturiert
Fremdbefund Laborwerte Histologiebefund Biopsiebefund Radiologiebefund Pathologiebefund Kardiologiebefund Entlassbefund||* Befund Fremdbefund Spezialbefund Laborbefund Histologie Biopsie Radiologie Pathologie Entlassbefund

Tabelle 18: Darstellung der Informationen zur Befundung in flacher oder substrukturierter Form, die Codes für die jeweiligen Abschnitte sind hier weggelassen. In der Praxis findet sich in der Regel bislang allein die flache Wiedergabe der Informationen.

Im folgenden Beispiel wird ein typischer Befund in Level 2 Notation dargestellt. Hinter dem text Element werden die Ergebnisse einer Befundaufnahme in Listenform repräsentiert.

<component> <section> <title>Befund</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> </component>

Diagnosen

Die Diagnosen werden im elektronischen Arztbrief im Idealfall

• in Level 1 & 2 tabellarisch angegeben,
• in Level 3 codiert angegeben.

Falls der narrative Text der Diagnosen (Text Element in Level 2) gänzlich aus codierten Entries abgeleitet ist, wird dies mit dem @typeCode DRIV (derived from) im entry Element angedeutet. Dies ist meist der Fall bei Diagnoseninformationen, die eigentlich vollständig hochcodiert in den Entries vorliegen und woraus der klinische Text erzeugt wird.

<component> <section> <text> Diagnosen im Freitext </text> <entry typeCode="DRIV"> <observation> strukturierte Diagnose (Code usw.) ... </observation> </entry> </section> </component>

Diagnosen in CDA Level 3

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

Abbildung 24: Observation Klasse des CDA Modells zur Angabe von strukturierten Diagnosen.

moodCode Mood-Code <= EVN Der Mood-Code der hier spezifizierten Diagnose ist immer EVN (Event), da es sich immer um ein Beobachtungsereignis handelt.

id Diagnosen-Identifikationsnummer SET<II> \[0..\*\] Es ist empfehlenswert, jeder Einzeldiagnose in einem System eine Identifikation zuzuordnen (II). Damit wird eine gezielte Diagnosen-Kommunikation möglich, zum Beispiel das Zuordnen von Diagnosen beim Update/Änderung bzw. Löschen von Angaben.

code Diagnose-Klassifizierung (Diagnosetyp) CD CWE \[1..1\] Hiermit wird der Typ der Diagnose, z. B. Aufnahmediagnose etc. spezifiziert (siehe unten).

negationInd Negations-Indikator (BL) Der negationInd zeigt, wenn er auf true gesetzt ist an, dass die Beobachtung negiert/verneint wird. Im Kontext mit Diagnosen heißt dies, dass eine Diagnose nicht zutrifft, ausgeschlossen ist (siehe unten). Das Modelattribut negationInd ist als Structural Attribute im root Element der Observation zu finden (siehe unten).

text ergänzende Erläuterungen zur Diagnose ED \[0..1\] Hier können ergänzende (ausführlichere) Erläuterungen zur Diagnose angegeben werden, so vorhanden. Bitte beachten: Dies ist nicht die Freitext-Diagnose. Diese findet sich im originalText Element des eigentlichen Diagnosewertes (value, siehe unten) wieder.

statusCode Statuscode <= completed Der statusCode einer Diagnose ist immer completed, da es sich immer um eine abgeschlossene Beobachtung handelt. Auch Verdachtsdiagnosen sind in diesem Sinne abgeschlossene Beobachtungen, in denen der Verdacht geäußert ist.

effectiveTime Zeitangabe Diagnose IVL<TS> \[0..1\] Zeitangaben, von wann (bis wann) die Diagnose gestellt wurde. Dies ist in der Regel ein Intervall, das normalerweise nur eine untere Grenze hat (low), dem Zeitpunkt der Diagnosestellung, von wo ab die Diagnose gültig ist. Ehemalige Diagnosen können zusätzlich auch noch das high Attribut als Obergrenze tragen.

value Diagnose-Code CD \[0..1\] Hier wird die eigentliche Diagnose codiert angegeben. Im Rahmen dieses Leitfadens ist die Diagnose mindestens als ICD 10 Code anzugeben. Regel DGCD: Verpflichtend bei den Diagnosen sind das @code Attribut und die Angabe zum Codesystem (OID) in @codeSystem.

<value xsi:type="CD" code="A25.1" codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006"/>

Zusätzlich kann der originale Freitext der Diagnose mit angegeben werden in originalText. Hier ist in CDA die Referenz auf die in Level 2 angegebene Diagnose vorgesehen. Der Text selber findet sich in der Level 2 Angabe. Siehe dazu auch den folgenden Abschnitt.

Zusammenhang zwischen Level 2 und Level 3 bei Diagnosen

Diagnosen werden in Level 2 angegeben, im Rahmen dieses Leitfadens optional auch auf Level 3 dargestellt. Level 2 enthält den Freitext zur Diagnose, während in Level 3 die Diagnose strukturiert und codiert angegeben wird. Wenn Level 3 Diagnosen wiedergegeben werden, ist mindestens ein ICD 10 Code zu verwenden.

Abbildung 25: Zusammenhang zwischen Level 2 und Level 3 bei Diagnosen

targetSiteCode Seitenangabe SET<CD> \[0..\*\] Der targetSiteCode beinhaltet Angaben zum anatomischen Situs, zur Seitenlokalisation oder zu dem System, das das Zielgebiet der Beobachtung ist, wenn diese Information nicht schon automatisch im Observation.code enthalten ist.

Angaben zu Diagnosen

Leider sind in Deutschland die Zusatzangaben zu den Diagnosen im stationären und im ambulanten Akutbereich sowie im Reha-Bereich nicht gleich. So ist unter anderem nicht in allen Bereichen die Diagnosesicherheit angebbar. Diese Problematik kann an dieser Stelle natürlich nicht aufgelöst werden, es bleibt hier lediglich zu hoffen, dass dies zukünftig vereinheitlicht wird. Die folgende Beschreibung zielt daher auch klar auf die Übermittlung der möglichen Varianten ab. So ist gewährleistet, dass jeder Sektor überhaupt Diagnosen in Level 3 übermitteln kann.

Zur vollständigen Angabe einer Diagnose sollten angegeben werden:

• Datum der Feststellung
• Diagnosetyp
• Diagnosecode
• Diagnose in Textform
• Sicherheit/Verlässlichkeit der Diagnose
• Seitenlokalisation
• Beschreibungen von Ausnahmen
• Sonstige Erläuterungen

Die einzelnen Angaben werden im Folgenden erläutert.

Datum der Diagnose

Das Datum der Diagnose (Feststellung) wird mit der größtmöglichen Genauigkeit (Jahr, Jahr und Monat oder Tagesdatum) angegeben. In Level 3 geschieht dies in der Form einer Zeitintervall-Angabe. Dies bedeutet, dass der Zeitpunkt der Diagnosenstellung die untere Grenze des Zeitinter¬valls darstellt.

<effectiveTime> <low value="20050825"/> </effectiveTime>

Diagnosetyp

Zum Diagnosetyp werden im hier spezifizierten Arztbrief die folgenden Diagnosetypen mit folgenden Typcodes zur Klassifikation unterschieden:

Code	Bedeutung	Erläuterung
ADMDX	Aufnahmediagnose	Diagnose bei Aufnahme des Patienten in die Gesundheitseinrichtung
DISDX	Entlassungsdiagnose	Diagnose bei Entlassung des Patienten in die Gesundheitseinrichtung
INTDX	Zwischendiagnose	Diagnose während des Aufenthalts des Patienten in die Gesundheitseinrichtung
FRGDX	Fremddiagnose	Eine Diagnose die aus einem anderen System importiert wurde.
ORDDX	Auftragsdiagnose	Diagnose vom Überweisungsschein

Tabelle 19: Diagnosetypen Codesystem: Sciphox (OID: 2.16.840.1.113883.3.7.1.50) Hinweis: Eine „Verdachtsdiagnose" ist eine der obigen Diagnosetypen mit dem Hinweis „V" (Zusatz). Siehe dazu auch Abschnitt 6.6.5.8 „Sicherheit/Verlässlichkeit der Diagnose". Es ist allerdings bekannt, dass nicht durch alle Systeme jeder Typ unterstützt wird.

Diagnose Code

Für die Codierung der Diagnosen muss die ICD 10 deutsche Fassung \[icd10gm2006\] benutzt werden. Die dafür vorgesehene OID des Code-Systems ist 1.2.276.0.76.5.311. Da die Observation Klasse für das value Element den abstrakten Datentyp ANY vorsieht, muss hier mittels der xsi:type Angabe der tatsächliche Datentyp, also hier eine Konzeptbeschreibung (concept descriptor CD), in den XML Dokumenten angegeben werden.

<value xsi:type="CD" code="A25.1" codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006"/>

Die Weitergabe von Freitextdiagnosen oder Diagnosen ohne ICD ist zu vermeiden. Die Angabe von freiem Text zur Umschreibung der Diagnose ist in Level 2 ohnehin vorgeschrieben. Regel DGCN: Fehlt der Code, so muss in der Level 3 Darstellung das code Element die Kennzeichnung erhalten, dass der Code unbekannt ist (XML Attribut @nullFlavor ist "UNK").

<value xsi:type="CD" nullFlavor="UNK"/>

Neben den anzugebenden ICD 10 Codes können auch zusätzlich alternative Codierungen spezifiziert werden. Diese werden als „Übersetzungen" (translation) zusammen mit dem ursprünglichen Code angebracht. Im folgenden Beispiel ist die Diagnose „Chronische ischämische Herzkrankheit: Ein-Gefäßkrankheit" sowohl wie verpflichtend als ICD 10 2006 codiert und zusätzlich als SNOMED CT \[snomedct\], IDMACS \[idmacs\] und AlphaID \[alphaid2006\] Diagnose (translation).

<value xsi:type="CD" code="I25.11" codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006"> ... <translation code="84537008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="Snomed CT"/> <translation code="I86822" codeSystem="1.2.276.0.76.5.309" codeSystemName="Alpha-ID 2006"/> <translation code="M0022B0-604046-30" codeSystem="1.2.276.0.76.5.305" codeSystemName="IDMACS"/> </value>

Diagnose in Textform

Die Diagnose in Textform (Langtext) wird im Text Element (Level 2) angegeben. Dabei kann in CDA die Referenz (originalText) auf die in Level 3 codierte Diagnose spezifiziert werden (vgl. dazu auch Abschnitt Zusammenhang zwischen Level 2 und Level 3 bei Diagnosen weiter oben). Der Freitext kann durchaus zusätzliche Informationen enthalten, die nicht notwendigerweise im Code mit enthalten sind, wie diagnosebezogene Begründungen, Notizen o.ä. Der Freitext ist nicht zu verwechseln mit dem aus dem Codierschlüssel des ICD 10 stammenden Diagnosetext. Dieser wird mit @displayName angegeben.

<component> <text> <content ID ="diag-1">Allergisches Asthma mit leichter Tendenz zur Besserung</content> </text> <entry typeCode="DRIV"> <observation> <value xsi:type="CD" code="J45.0" codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006"/> <originalText> <reference value="\#diag-1"/> </originalText> ... </value> ... </observation> </entry> </component>

Sicherheit/Verlässlichkeit der Diagnose

Als Angaben der Sicherheit/Verlässlichkeit der Diagnose aus dem KV-Bereich ist hier in Level 2 der Text anzugeben: „Gesichert", „Verdacht auf", „Zustand nach", „Ausschluss von". Die Angabe zur Sicherheit ist im Rahmen der Abrechnung mit den gesetzlichen Krankenkassen eine Pflichtangabe, bei Rechnungen für Privatversicherte ist die Angabe von "Gesichert" nicht möglich. Im stationären Bereich sind Angaben zur Sicherheit/Verlässlichkeit der Diagnose nicht üblich, was ggf. zu Falschinterpretationen führen kann. Auf Level 3 werden die verschiedenen Zustände unterschiedlich gehand¬habt. Zum value Element des Codes kommt hier ein zusätzliches qualifier Element, dass die Sicherheit der Diagnose angibt.

Code	Bedeutung	Erläuterung
G	Gesichert	Gesicherte Diagnose
V	Verdacht auf	Verdachtsdiagnose
Z	Zustand nach	Zustand nach
A	Ausgeschlossene Erkrankung	Ausgeschlossene Erkrankung, gleichzeitig ist dies in Level 3 mittels negationInd anzugeben (siehe auch Hinweis im Text)

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

<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"/> <value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/> </qualifier> </value> </observation>

Hierbei ist unbedingt zu beachten, dass im Falle eines Ausschlusses einer Erkrankung bei der Darstellung in Level 3 in der Observation Klasse der negationInd ebenfalls gesetzt sein muss, d. h. negationInd="true". Ferner gilt: Regel DGQL: Ist in einer Level 3 Diagnose ein qualifier Element anwesend, muss ein name und ein value Kindelement mit Codes vorhanden sein.

<observation classCode="OBS" moodCode="EVN" negationInd="true"> ... <value ... <qualifier> <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/> <value code="A" codeSystem="2.16.840.1.113883.3.7.1.8"/> </qualifier> </value> </observation>

Hinweis: Systeme, die Diagnosen auf Ebene Level 3 nicht wie beschrieben semantisch korrekt abbilden und verarbeiten können (z. B. Diagnosezusatz „Ausschluss von") müssen sich auf Verarbeitung und Darstellung von maximal Level 2 (Freitext) mit Angabe aller Zusätze beschränken.

Seitenlokalisation

Für die Angabe der Seitenlokalisation, also links, rechts oder beidseitig etc. wird in Level 2 „links", „rechts" etc. oder die übliche abkürzende Schreibweise L, R etc. benutzt. In Level 3 wird die Seitenlokalisation im qualifier unterhalb des code Element wiedergegeben. Hierzu ist folgende Codetabelle zu verwenden.

Code	Bedeutung	Erläuterung
L	links	Seitenlokalisation links
R	rechts	Seitenlokalisation rechts
B	beidseitig	Beidseitiges Auftreten
U	unbekannt	Seitenlokalisation nicht bekannt

Tabelle 21: Vocabulary Domain für Seitenlokalisation Codesystem: Sciphox (OID: 2.16.840.1.113883.3.7.1.7)

<observation classCode="OBS" moodCode="EVN"> ... <value xsi:type="CD" ..."> <qualifier> <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/> <value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/> </qualifier> </value> </observation>

Beschreibungen von Ausnahmen

Mögliche Beschreibungen von Ausnahmen stellen z. B. für geschlechtsspezifische Plausibilitätsprüfungen eine Begründung dar, beispielsweise warum man eine eigentlich weibliche Diagnose (bösartige Neubildung der Brustdrüse) bei einem Mann angesetzt hat. Diese Begründungen werden in jedem Falle mit im Text in Level 2 ausgegeben. Zusätzlich kann ein weiterer Entry in Level 3 an die Diagnose gelinkt werden. Da es sich um eine Begründung handelt ist hier der entryRelationship.typeCode RSON (reason). Die Begründung wird im value Element als Text wiedergegeben, eine Klassifikation der Begründung (code Element ist zurzeit noch nicht vorgesehen).

<observation classCode="OBS" moodCode="EVN"> ... <value ... bösartige Neubildung der Brustdrüse /> <entryRelationship typeCode="RSON"/> <observation> ... <value xsi:type="ED"> Begründung für obige Diagnose </value> </observation> </entryRelationship> </observation>

Sonstige Erläuterungen

Weitere Erläuterungen, z. B. Eintragungen bei meldepflichtigen Diagnosen, werden in Level 2 als zusätzlicher Text und in Level 3 als nicht näher spezifizierte Referenz (REFR) zu der Beobachtung als weitere Observation aufgeführt (entryRelationship.typeCode REFR). Sie sind in diesem Leitfaden nicht in Level 3 repräsentiert.

Beispiele

Im folgenden Übersichtsbeispiel wird eine Diagnose als ICD 10 Code C62.9, bösartige Neubildung des Hodens links wiedergegeben. Die Diagnose ist gesichert.

<component> <section> <title>Diagnosen mit ICD 10</title> <text> <thead> </thead> <tbody> </tbody> Diagnose ICD Code Lokalisation Zusatz <content ID="diag-1"> Bösartige Neubildung des Hodens </content> C62.9 L G </text> <entry> <observation classCode="OBS" moodCode="EVN"> <statusCode code="completed"/> <effectiveTime> <low value="20050825"/> </effectiveTime> <value xsi:type="CD" code="C62.9" codeSystem="1.2.276.0.76.5.311" codeSystemName="icd10gm2006"/> <originalText> <reference value="\#diag-1"/> </originalText> <qualifier> <name code="8" codeSystem="2.16.840.1.113883.3.7.1"/> <value code="G" codeSystem="2.16.840.1.113883.3.7.1.8"/> </qualifier> <qualifier> <name code="7" codeSystem="2.16.840.1.113883.3.7.1"/> <value code="L" codeSystem="2.16.840.1.113883.3.7.1.7"/> </qualifier> </value> <entryRelationship typeCode="RSON"> <observation> <value xsi:type="ED">bevorstehende Geschlechtsumwandlung, \’amtliches\’ Geschlecht bereits weiblich, Operation steht jedoch noch aus </value> </observation> </entryRelationship> </observation> </entry> </section> </component>

Besondere Hinweise (Cave)

In dem Abschnitt CAVE werden

• Hinweise zu Risikofaktoren beim Patienten
• Allergien

abgebildet.

<component> <section> <text>Penicilinallergie</text> </section> </component>

Therapien/Behandlungsmaßnahmen

In dem Abschnitt Therapie werden u. a.

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

abgebildet.

<component> <section> <title>Therapien – Jetzige Medikation</title> <text>Atemur morgens 2x und abends 2x</text> </section> </component>

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

Prozeduren in CDA Level 3

Behandlungsmaßnahmen, die direkt den Patientenzustand verändern, werden als Procedure Klasse in Level 3 wiedergegeben. In diesem Leitfaden sind diese Prozeduren als bereits stattgefundene (abrechnungsrelevante) Behandlungsmaßnahmen klassifiziert.

Abbildung 26: Procedure Klasse des CDA Modells zur Angabe von strukturierten Prozeduren. moodCode Mood-Code <= EVN Der Mood-Code der hier spezifizierten Prozeduren ist immer EVN (Event), da es sich immer um stattgefundene Prozeduren handelt.

id Prozedur-Identifikationsnummer SET<II> \[0..\*\] 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.

code Prozedur-Klassifizierung (Prozedurtyp) CD CWE \[1..1\] 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. Zu beachten ist, dass bei OPS Codes ebenfalls eine Seitenlokalisation mitgegeben werden muss (siehe dazu Abschnitt 6.6.5.9 „Seitenlokalisation" bei Diagnosen).

@negationInd Negations-Indikator (BL) 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.

text ergänzende Erläuterungen zur Prozedur ED \[0..1\] 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.

statusCode Statuscode <= completed Der statusCode der hier spezifizierten Prozeduren ist immer completed, da es sich immer um eine abgeschlossene Behandlungsmaßnahme handelt.

effectiveTime Zeitangabe Prozedur IVL<TS> \[0..1\] Zeitangaben, von wann an (bis wann) die Prozedur durchgeführt wurde. Dies ist in der Regel ein Zeitpunkt.

methodCode Klassifizierung der Methode SET<CE> CWE \[0..\*\] 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.

approachSiteCode Klassifizierung der Zugangsmethode SET<CD> CWE \[0..\*\] Der anatomische Situs oder das System, über das die Behandlungsmaßnahme ihr Ziel erreicht. Zum Beispiel kann eine Nephrektomie als trans-abdominaler Eingriff oder mit retroperitonealem Zugang ausgeführt werden. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet. Beim OPS Code ist die Zugangsmethode bereits im Code enthalten.

targetSiteCode Klassifizierung des Zielgebiets SET<CD> CWE \[0..\*\] Der anatomische Situs oder das System, auf das die Behandlungsmaßnahme abzielt. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet.

<component> <section> <title>Maßnahmen / Behandlungen</title> <text> <list> <item>24.11.2005: <content ID="proc-1">Sonographie der männlichen Geschlechtsorgane</content> </item> </list> </text> <entry> <procedure classCode="PROC" moodCode="EVN"> <originalText> <reference value="\#proc-1"/> </originalText> <qualifier> <name code="7" codeSystem="2.16.840.1.113883.3.7.1"/> <value code="B" codeSystem="2.16.840.1.113883.3.7.1.7"/> </qualifier> <statusCode code="completed"/> <effectiveTime value="200511241517"/> </procedure> </entry> </section> </component>

Notizen

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.

<component> <section> <title>Notizen</title> <text> .... </text> </section> </component>

Epikrise

In dem Abschnitt Epikrise werden

• der zusammenfassende Rückblick
• die Empfehlung
• die Prognose

abgebildet.

<component> <!—Epikrise Komponente am Beispiel einer Empfehlung --> <section> <title>Empfehlung</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> </component>

Anhänge

Der Bezug auf die an einem Arztbrief zugeordneten zusätzlichen Befunde (z.B. digitale Bilder) werden in diesem Abschnitt abgebildet. Externe Dokumente wie z. B. weitere CDA Arztbriefe werden über die ExternalDocument Klasse referenziert (siehe dazu auch Abschnitt 6.6.12).

<component> <section> <text> Bild vom Befund an der linken Hand </text> <entry> <observationMedia classCode="OBS" moodCode="EVN"> <id root="10.23.4567.345.46.232434"/> <value mediaType="image/jpeg"> <reference value="lefthand.jpeg"/> </value> </observationMedia> </entry> </section> </component>

Schlusstext

Der Schlusstext eines Arztbriefes wird in diesem Abschnitt abgebildet.

<component> <section> <text> Mit freundlichen, kollegialen Grüßen </text> </section> </component>

Externe Dokumente

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.

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

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

@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.

@seperatableInd getrennt betrachtbares Dokument BL \[0..1\] 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.

id Identifikation des extenen Dokuments Angaben dazu werden gewöhnlich über die Id des Dokuments gemacht.

code Dokumententyp CE CWE \[0..1\] Über das code Modellattribut der ExternalDocument Klasse wird eine Typisierung des Dokuments vorgenommen.

text Mime-Type Andeutung des externen Dokuments Im text Element, modelliert als ED Datentyp, wird der Mime-Type des externen Dokuments angegeben.

setId Set-Kennung des externen Dokuments II \[0..1\] versionNumber Versionsnummer des externen Dokuments INT \[0..1\] Mittels der Attribute setId und versionNumber kann eine Versionskennung des externen Dokuments erreicht werden (siehe hierzu auch Abschnitt 5.11).

<entry> <observation classCode="COND" moodCode="EVN"> <value xsi:type="CD" code="..." ...> <originalText> <reference value="\#a2"/> </originalText> </value> <reference typeCode="SPRT"> <seperatableInd value="false"/> <externalDocument> <id root="123.456.789"/> <text mediaType="multipart/related"> <reference value="CDA452365637.cda"/> </text> <setId root="147.89.9001"/> <versionNumber value="1"/> </externalDocument> </reference> </observation> </entry>

LABORBEFUNDE

gemeinschaftliche Definitionen und Transport

== Datentypen== Zu den in diesem Leitfaden verwendeten Datentypen kann das Dokument „HL7 Version 3 Datentypen und CMETs für das Deutsche Gesundheitswesen" \[dtcmetv3-hl7de\] konsultiert werden, das die nationalen Festlegungen der HL7 Version 3 Datentypen enthält.

Transport

Für die physikalische Übermittlung des CDA Dokuments, sprich wie das Dokument von A nach B übertragen wird, gibt es mehrere technische Alternativen. Etablierte Verfahren stellen einerseits branchenunabhängige Lösungen wie die Mailkommunikation über SMTP/POP3, der einfache Dateiaustausch und andere dar, andererseits die auf den Gesundheitsmarkt fokussierten Konzepte wie XDS nach IHE oder die Interaktionen aus der Medical Records Domäne von HL7 und weitere. In dem Implementierungsleitfaden für den Arztbrief wird keine Präferenz für eine bestimmte Lösung vorgenommen. Das Thema Transport ist grundsätzlich unabhängig von den Inhalten des CDA Dokuments zu behandeln und wird folglich auch außerhalb des Implementierungsleitfadens dokumentiert. Aufgrund der gesetzlichen Grundlage nach §291a ff SGB V und der Beauftragung der gematik GmbH zur Erarbeitung eines gesamthaften Konzepts zur Einführung einer nationalen Telematikinfrastruktur, wird die Entwicklung einer einheitlichen Lösung für den "Transport" des Arztbriefes bei der gematik gesehen. Die gematik wurde von den Spitzenorganisationen des deutschen Gesundheitswesens gegründet, um die Einführung der elektronischen Gesundheitskarte (eGK) voran zu treiben. Da die Arbeiten der gematik zum jetzigen Zeitpunkt nicht abgeschlossen sind und die Rahmenbedingungen für den Transport von Arztbriefen über die Telematikinfrastruktur der eGK nicht geklärt sind, muss die Auswahl des besten Transportmechanismus projektspezifisch erfolgen.

Hinweise zur Verwendung Digitaler Signaturen

Die gesetzlichen Rahmenbedingungen und die Verwendung von digitalen Signaturen sind im Signaturgesetz geregelt \[SigG\] \[SigV\]. Die Umsetzung zur Signatur der Inhalte von XML Dokumenten kann über verschiedene Methoden realisiert werden \[XMLSig\]. Im Hinblick auf die bevorstehende Einführung einer Telematikinfrastruktur, des Heilberuflerausweises und des eRezepts mit digitaler Signatur wird hier auf eine ausführliche, verbindliche Beschreibung verzichtet und ggf. in einem zukünftigen Dokument ausgeführt.

Bei der Frage, ob das Stylesheet für die Ansicht oder den Ausdruck von CDA Dokumenten mit signiert werden muss, lässt sich sagen, dass dies nicht der Fall ist. Digitale Signaturen im Sinne des Signaturgesetzes beziehen sich auf den Inhalt und Zweck des signierten Dokuments. Gerade CDA ist wegen der in diesem Dokument erläuterten Absichten der Attribute und Elemente für sich und ohne ein Stylesheet bereits Inhalt und Zweck genug. Somit ist die Signatur mitsamt des Stylesheets nicht notwendig. Hingegen ist bei mitgelieferten und mitsignierten Dateien für Bilder die Betrachtung wesentlicher Teil des Zwecks, und daher sind für Bilder und weitere Multimedia-Objekte entsprechende Formate und Standard-Betrachtungsprogramme zu vereinbaren, um die Gültigkeit der Signatur zu erhalten. Besonders der Einsatz von qualifizierten Signaturen und Zertifikaten ist im Signaturgesetz festgeschrieben, wonach die Signatur prüfbar, qualifizierte Zertifikate nachzuprüfen und deren Ergebnisse anzuzeigen sind. Somit ist der Einsatz entsprechender Betrachtungssysteme bei qualifizierten Signaturen obligat.

Unterstützende Dokumente

Dieses Kapitel ist nicht normativ. Im Rahmen dieses Leitfadens wurde ein Set von elektronisch verfügbaren Dokumenten zusammengestellt bzw. erstellt, die im Einzelnen aufgeführt sind. Die Dokumente sind in Ordnern sortiert:

• schema enthält die Hauptschemas, Beispieldokumente, Templates und Stylesheets
• coreschemas enthält allgemeine Schemas wie Datentypen-Definitionen, Vokabularien und Definitionen für den narrativen Textteil.

Schemas

CDA Release 2 umfasst ein Set von XML Schemas, die zur Validierung von CDA Dokumenten verwendet werden müssen. Einstiegsschema ist

• CDA.xsd

welches eine Reihe von weiteren Schemas aufruft:

• POCD_MT000040.xsd, enthält das CDA Schema für Header und Body Release 2

Diese Schemas befinden sich im Unterordner schema. Darüber hinaus sind weitere Schemas im Ordner coreschemas enthalten

• datatypes.xsd mit den Definitionen der Datentypen, verwendet datatypes-base.xsd
• voc.xsd mit den Definitionen zu Vokabularien und
• NarrativeBlock.xsd mit Definitionen für den narrativen Textteil.

Beispiel Dokumente

Zu den in diesem Leitfaden vorgestellten Storyboards gibt es Beispiel-Dokumente als CDA Release XML Instanz.

• vhitg-POCD_EX00000\*.xml, enthält Informationen in Anlehnung an die im Leitfaden genannten Storyboards POCD_SN00000\*DE, wobei \* die Storyboardnummer repräsentiert.

Zu Referenzzwecken ist das Original Beispiel-Dokument aus dem CDA Standard beigefügt.

• SampleCDADocument.xml

Die jeweils mit den Stylesheet (siehe unten) gerenderte Fassung ist ebenfalls mit dem Suffix .html beigefügt.

Stylesheet

Dieser Leitfaden stellt ein Stylesheet zur Verfügung, dass zur Visualisierung eines CDA Dokuments verwendet werden kann.

• vhitg-cda-v\*.xsl, wobei \* die Versionsnummer repräsentiert.

Es ist aus einem finnischen Projekt entstanden (HL7 Finland CDA R2 Tyylitiedosto, Tyyli_R2_B3_01.xslt) und wurde anschließend von Calvin E. Beebe (Mayo Clinic, Rochester) und Keith W. Boone (Dictaphone, Burlington) weiter verfeinert. Kai U. Heitmann (Heitmann Consulting & Service, Niederlande) und Erich Gehlen (Duria eG) bearbeiteten das Stylesheet für das VHitG-Projekt.

Templates/Profile

Im Rahmen dieser Version des Leitfadens wurden bisher nur testweise Templates/Profile zur weiteren Validierung der CDA Dokumente erstellt.

• Das Unterverzeichnis rules enthält ruleset-vvv.sch, diese enthält die Schematron-Anweisungen zum Überprüfen der in definierten Rulesets aus der Version vvv. Bei der Verwendung von Templates wird damit die Template ID 'CDA-R2-AB100-ruleset-vvv-aaaa' angedeutet, wobei aaaa die Kennung des Rulesets repräsentiert.

Anhang

Dieses Kapitel ist nicht normativ.

HL7

HL7 (Health Level Seven) ist der weltweit eingesetzte und anerkannte Kommunikationsstandard im Gesundheitswesen. Im Vordergrund stand dabei bisher der Austausch von Nachrichten, sowohl für administrative als auch klinische Belange. HL7 Version 3 \[HL7V3\] definiert eine neue Generation von Kommunikations¬standards für die Spezifikation, Entwicklung und Pflege von Nachrichten im gesamten Gesundheitswesen. Dies wird mit einer ausgereiften Methodik zur modell-basierten und Werkzeug-gestützten Entwicklung zugeschnittener Nachrichten erreicht. Zahlreiche Projekte wurden bereits mit HL7 Version 3 Spezifikationen erfolgreich durchgeführt. Viele europäische Länder, darunter die Niederlande, Großbritannien und Dänemark, haben HL7 Version 3 als strategisches Konzept für eine landesweite Kommunikation im Gesundheitssektor gewählt. In England wurde vom National Health Service (NHS) bereits vor zweieinhalb Jahren das GP2GP-Projekt initiiert, das sich gerade HL7 Version 3 zur Unterstützung für die Kommunikation Niedergelassener zu Nutze machte. Daraus ist mittlerweile ein nationales, staatlich stark gefördertes und deutlich ausgedehntes Projekt geworden. Auch in Deutschland ist in den zurzeit vom Gesundheitsministerium initiierten Bestrebungen rund um die elektronische Gesundheitskarte (bIT4health) aktiv HL7 Version 3 als Zieltechnologie und Kernelement sektorenübergreifender IT-Anwendungen vereinbart worden. Die für dieses Projekt zur Anwendung gelangenden Basis-Modelle kommen aus dem Bereich „Health&Clinical Management", der Domäne „Patient Care Provision" und „Clinical Documents".

Hinweis: in dieser Spezifikation kann naturgemäß nur sehr eingeschränkt auf die HL7 Version 3 Nachrichtenkonzepte und Methodologie eingegangen werden. Es wird empfohlen, entsprechende weiterführende Informationen zu Rate zu ziehen (z. B. \[HL7V3\]) oder entsprechende Fortbildungsangebote zu nutzen.

Hinweise zur Vergabe und Verwendung von Object Identifiern (OIDs)

Identifikationen von Objekten

In HL7 muss für jeden der beteiligten Kommunikationsteilnehmer (Systeme, die an der Kommunikation teilnehmen, sog. Devices) ein eindeutiger Object Identifier (OID) existieren \[OIDK\]. Das bedeutet für die Software, dass bei den Stammdaten einer jeden Senderinstanz für alle Kommunikationspartner eine eindeutige OID bekannt sein muss. Auch ein Heilberufler ist eindeutig mit einer OID zu versehen. Dabei ist zu beachten, dass ein Arzt selber in diesem Sinne nicht als Sender- oder Empfänger-Gerät auftritt, sondern als Person z. B. in der Rolle Autor. Es handelt sich also um verschiedene OIDs, sendende und empfangende Anwendungen müssen darüber hinaus auch identifizierbar sein. Eine mögliche und häufig anzutreffende Lösung ist, dass die Hersteller, die sendende Systeme installieren, die OID selbst vergeben. Dabei wird davon ausgegangen, dass jeder Hersteller über eine eigene OID verfügt. Diese wird rechts ergänzt um eine innerhalb des Unternehmens eindeutige Kennung für die jeweilige konkrete Installation (Instanz der Anwendung, bzw. Mandant). Daran angehängt werden die jeweils benötigten Kennungen für die verschiedenen mit einem Identifikator zu versehenden Objekte, wie Dokumenten-Id, Diagnosen-Id, etc. Verwenden mehrere Software-Prozesse und/oder mehrere Arbeitsplätze einer Praxis/Abteilung/Klinik denselben OID-Zähler, so muss der Zugriff auf diesen Zähler serialisiert sein. Ist dies zu aufwändig, müssen separate Zähler mit jeweils unterschiedlichem Präfix für jede parallel arbeitende Instanz eingerichtet werden. Beispiel: Es sei 1.2.3.4.5 die OID eines Systemherstellers. Er ergänzt diese nach rechts um .67, also 1.2.3.4.5.67. Dies soll die Wurzel OID für alle Installationen/Systeminstanzen dieses Herstellers andeuten. Daran anzuhängen wäre dann durchnummeriert eine Zahl für jede Installation, die der Hersteller irgendwo installiert hat. Die Installation des Systems in Arztpraxis A bekäme demnach eine .1 angehängt, was einer Gesamt-OID von 1.2.3.4.5.67.1 entspräche, die Installation im Krankenhaus K bekäme die .2 angehängt und so weiter. Eine Dokumenten-Id ist durch anhängen einer .7 an die Installationskennung (OID) gekennzeichnet. Ein entsprechendes Dokument hätte danach im id Element der ClinicalDocument Klasse als @root die OID 1.2.3.4.5.67.2.7 und eine entsprechende eindeutige Dokumenten¬kennnummer im @extension Attribut, die innerhalb des sendenden Systems eindeutig sein muss. Gleiches Vorgehen wird auch für die eindeutige Kennung von z. B. Diagnosen, Prozeduren usw. verwendet, wo statt der .7 für Dokumente eine .18 für Diagnosen, eine .19 für Prozeduren angehängt um um die eindeutige interne Nummer ergänzt wird. Hierbei handelt es sich – wie gesagt – um ein Beispiel, es sind auch andere Vorgehensweisen denkbar oder in realen Implementationen zu finden. Der Hersteller hat dabei dafür Sorge zu tragen, dass jede OID nur einmal vergeben wird und bei Änderungen der Zuordnung von OIDs eine neue OID zur Anwendung kommt. Einzige Verpflichtung des Herstellers ist also, dass Objekte mit dem OID Konzept weltweit eindeutig und dauerhaft identifiziert werden können.

Identifikationen von Codesystemen

Auch die Nutzung der bei HL7 verpflichtend anzugebenden Codesysteme bei der Übermittlung von Codes und anderen Klassifikationen, die ebenso mittels einer OID verwaltet und in Dokumenten spezifiziert werden, stellt ggf. neue Anforderungen an die Hersteller von Software. Im Prinzip muss zu jedem verwendeten Codewert das zugehörige Codesystem im Sinne einer OID bekannt sein.

Allgemeine Anmerkungen zum Interaktionsmodell

Das hier beschriebene Interaktionsmodell basiert auf Überlegungen des IHE Profils „Cross-Enterprise Document Sharing" (XDS) und fügt einige Aspekte zum Thema „Sicherheit" und "Gesundheitskarte" (eGK) hinzu. Die gesetzlichen oder technischen Anforderungen an die Informationssicherheit im Umfeld der eGK können – bei gleicher Funktionsweise – den Ersatz der hier verwendeten Datenelemente (z.B. durch Referenzen, Schlüssel oder verschlüsselte Inhalte) notwendig machen. Die hier beschriebenen Abläufe bleiben durch derartige Anpassungen logisch unverändert. Die Erläuterungen sind abstrakt und unabhängig von der Transportschicht zu sehen und stellen die auf logischer Ebene zum Einsatz kommenden Akteure dar. Es erfolgen darüber hinaus keine Festlegungen zu den Nachrichtentypen für die einzelnen Transaktionen. Bei den beschriebenen Modellvarianten wirken folgende Akteure mit ihren entsprechenden Aufgaben zusammen:

Sender:	IT-System, in dem der „Arztbrief" erzeugt und versendet wird. Der Sender ist technisch gesehen für die Erstellung valider Arztbriefe verantwortlich und muss gleichzeitig eine Speicherfunktion übernehmen („Custodian" des Dokuments)
Empfänger	IT-System, das freigegebene Arztbriefe empfängt, z. B. umd diese zu speichern oder anzuzeigen
Repository	IT-System zur Bereitstellung von abfragbaren Arztbriefen. Das Repository ist in der Regel als Teil des Senders und auch des Empfängers realisiert, kann jedoch auch getrennt betrieben werden, beispielsweise im Sinne eines zentralen Repositories (elektronische Patientenakte). Das Repository muss für die betroffenen Akteure (möglichst) ständig verfügbar sein.
Registry	IT-System, das Anfragen nach der Dokumenten-Verfügbarkeit im Repository beantwortet oder/und Nachrichten über die Bereitstellung versendet. Der Betrieb ist mit dem Repository zusammen oder separat möglich. Somit kann die Registry auch Teil eines Sender oder Empfängers sein. Eine mögliche Realisierung einer Registry ist beispielsweise ein Verzeichnis von Verweisen auf Dokumente, die in einem permanenten Speicher verwaltet werden. Die Registry muss für die anderen Akteure (möglichst) ständig verfügbar sein.
Patient	Der „Patient" nimmt mit einer definierten Identität, sein informationelles Selbstbestimmungsrecht und den technischen Möglichkeiten des Zugriffs auf „seine" Daten eine eigene Rolle ein, die sich von der des Anwenders des Empfängersystems, sprich dem Arzt, beispielsweise aufgrund des eGK-Konzeptes und der Sicherheitsprofile technisch unterscheidet.

In der weiteren Beschreibung nicht aufgeführte, aber relevante Akteure:

MPI	IT-System, das Anfragen bezüglich Personen-Iden¬titäten beantwortet (vgl. Akteur „PIM" aus den Arbeiten der VHitG Initiative „AG PID" oder IHE Profil „ITI PIX" oder Versichertendatendienst zur eGK-Einführung)
Autor	Die an der Entstehung des Arztbriefs beteiligte Person, die den Urheber des Arztbriefs beim Sender darstellt. Der konkrete Autor kann beispielsweise sein: Urheber, Datenerfasser, medizinischer Verantwortlicher, juristischer Verantwortlicher
Reader	IT System, das die Anzeige des Arztbriefes in dem Empfänger übernimmt. In der Regel wird von einem kombinierten System ausgegangen, in dem Empfänger und Reader als integrierte Lösung von einem IT Anbieter angeboten wird. Dieser Akteur wird nicht weiter beschrieben.

Interaktionsmodell für den Use Cases 1, vollständiger Arztbrief

Bei der Erstellung des Arztbriefes kommen die Akteure Sender, Repository und Registry zum Einsatz. Repository und Registry können physikalisch ein gemeinsames IT System darstellen, sind logisch aber zwei Akteure. Es ist bei regionaler oder flächendeckender Umsetzung des Konzepts davon auszugehen, dass die Registry logisch gesehen als zentraler Knoten realisiert ist und mehrere Repositories verwaltet. Bei der Übermittlung von Dokumenten ist zu beachten, dass sowohl die gerichtete als auch die ungerichtete Kommunikation umzusetzen ist. Hieraus ergeben sich bestimmte Vorgaben zu den Interaktionen, wie z.B. der Übermittlung der Empfangsbestätigungen u. a.

Versand des Arztbriefs

Diese Situation ist in Abbildung 28 gelb unterlegt. Der zu übermittelnde Arztbrief wird vom Sender in einem unteilbaren Schritt im Rahmen der endgültigen Freigabe mit einer Dokumenten-Identifikation (mittels Object Identifier, kurz OID) und den relevanten Headerdaten, z. B. dem Zeitpunkt der Erzeugung (effectiveTime) versehen (1). Optional kann das Dokument bezüglich des Autors unter zu Hilfenahme des Heilberuflerausweises (HBA) signiert, bezüglich des Patienten unter zu Hilfenahme der elektronischen Gesundheitskarte (eGK) verschlüsselt und an das Repository versendet werden. Die zu sendende Nachricht besteht aus dem Dokument selbst in verschlüsselter Form. Zusätzlich enthält sie in unverschlüsselter Form die Sender- und Empfängerkennung, den Autor, die Patientenkennung sowie die wichtigsten Kennzeichen des Arztbriefs (Identifikation, Klassifizierung). Das Repository speichert die Daten so ab, dass sie über bestimmte Abfrageparameter wie die OID, Patientenkennung oder Erstellungsdatum gefunden etc. werden können (2). Das Repository bestätigt gegenüber dem Sender den Nachrichtenempfang nach der Speicherung der Nachrichteninhalte (3). War der Speichervorgang nicht erfolgreich, übermittelt das Repository dem Sender eine entsprechende Fehlermeldung. Der Sender kann das Dokument mit der Nachricht erneut senden (ggf. nach Ausräumen der Fehlerursachen). Die Empfangsbestätigungen sind als Antwort der jeweils empfangenden Anwendung zu verstehen. Die Anwendung sagt also, dass sie die Nachricht verstanden hat und bearbeiten kann. Durch darunterliegende Protokolle können weitere Quittungen etc. notwendig sein, es wird jedoch mindestens die hier explizit dargestellte Empfangsbestätigung versendet. Das Repository sendet schließlich eine Mitteilung an die Registry zusammen mit den Basisdaten (d. h. Autoren, Patientenkennung sowie die wichtigsten Kennzeichen des Arztbriefs, aber ohne das eigentliche Dokument), um das Vorhandensein eines neuen Dokuments anzuzeigen. Dabei wird als „Standort" des Dokuments die eigene Repository-Adresse an die Registry gemeldet (4). Die Registry speichert die Daten, so dass sie später über bestimmte Abfrageparameter wie die OID oder die Erstellungsdatum etc. gefunden werden können (5). Die Registry bestätigt gegenüber dem Repository den Nachrichtenempfang nach der Speicherung der Nachrichteninhalte (6). Die Bestätigung des Repository an den Sender erfolgt nach Abschluss der Kommunikation mit der Registry. Ist die Registrierung nicht erfolgreich, so wird das Dokument nicht im Repository gespeichert und der Sender erhält eine Fehlermeldung.

Abfrage der Registry

Dies ist in Abbildung 28 grün unterlegt und beschreibt die Situation, dass der Patient bereits zuvor beim Arztbrief-Empfänger (niedergelassener Arzt) war oder gerade anwesend ist. Der Empfänger kennt daher die Patientenkennung, mit der er die Registry nach vorhandenen Arztbriefen fragt. In dieser Abfragenachricht, der „Query", ist beispielsweise die Empfänger- und Patientenkennung sowie Zeitinformationen enthalten (7). Die Antwort der Registry ist eine Liste der bekannten Daten aller Arztbriefe zu diesem Patienten beispielsweise mit „Autor, Datum, OID, Quell-Adresse" der vorliegenden Arztbriefe für den durch die Abfrage identifizierten Patienten (8). Ggf. werden hier auch Filtermechanismen wirksam, die zum Beispiel juristisch oder inhaltlich (Klassifizierung der Dokumente) begründet sein können. Der Empfänger zeigt die empfangene Liste an, so dass der Arzt eine Auswahl treffen kann (9). Hinweis: Alternativ zu dem Query/Response Konzept kann auch eine Benachrichtigung über die Verfügbarkeit des Arztbriefes im Repository an die Empfängersysteme kommuniziert werden (vgl. auch IHE-NAV). In diesem Fall ist die Query/Response als alternativer oder zusätzlicher Mechanismus zu sehen.

Abfrage eines vorhandenen Arztbriefs für einen Patienten

Diese Situation ist in Abbildung 28 blau unterlegt. Nach der Abfrage des Registry durch den Empfänger (7, 8) und Auswahl des Arztbriefes durch den Anwender bzw. die Anwendung wird der Arztbrief aus dem Repository abgerufen (10). Für den Abruf werden die OID des Arztbriefes und Zusatzkennzeichen wie die Empfängerkennung und Zeitinformationen zur Zuordnung der Antworten genutzt. Die Antwort vom Repository enthält das ggf. verschlüsselte Arztbriefdokument (11). Die Transaktion ist identisch mit (1). Der Empfänger muss den Arztbrief temporär oder langfristig speichern (12), wobei er den Status des Speichervorgangs an das Repository zurückmeldet (13), analog zu (2) und (3). Mit der eGK (ggf. PIN) des anwesenden Patienten wird der Arztbrief beim Empfänger entschlüsselt. Mit dem public-key des Senders kann die Signatur verifiziert werden. Sollte die Telematik-Infrastruktur eine entsprechende elektronische Bevollmächtigung (eMandat) durch den zuvor anwesenden Patienten unterstützen, so kann auch ein derartiges eMandat zur Entschlüsselung eingesetzt werden, so dass sich der empfangende Arzt auf den Patientenbesuch vorbereiten kann. Nach diesen Schritten kann der Arztbrief als Klartext in das IT-System des Empfängers übernommen werden, optional zur temporären oder langfristigen Speicherung (12). Den Status des Speichervorgangs meldet er an das Repository zurück (13) wobei der Empfänger die Statusmeldung an das Repository sendet.

'Abbildung 28: Interaktionsmodell für Use Case „Vollständiger Arztbrief"' Der beschriebene Ablauf ist idealisiert und vereinfacht dargestellt. Zu berücksichtigen sind darüber hinaus Aspekte des Datenschutzes, der Sicherheit zur Authentisierung der Systeme und Anwender, der Verschlüsselung, der Signatur und klare Regeln im Umgang mit dem Errorhandling. Diese Aspekte sind nicht Fokus des vorliegenden Leitfadens, sondern zentrale Aufgabe der gematik und weiterer Organisationen.

Hinweise zum Versand von XML-Stylesheets

XML Sytelsheets werden zur Visualierung der XML-Dokumente verwendet. Es wird empfohlen, bei jedem Arztbrief das zugehörige (und ggf. mehrere weitere) Stylesheets mitzusenden.

== Referenzen==

Allgemein und HL7

\[HL7V3\] HL7 Version 3 http://www.hl7.org Abstimmungsverfahren Ballot 11, September 2005 \[XMLSC\] World Wide Web Consortium. XML Schema. http://www.w3.org/TR/xmlschema-0/ http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/ + World Wide Web Consortium. XML Schemas Part 1: Structures. http://www.w3.org/TR/xmlschema-1/ + World Wide Web Consortium. XML Schemas Part 2: Datatypes. http://www.w3.org/TR/xmlschema-2/ \[XML\] World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition. http://www.w3.org/TR/REC-xml \[OIDK\] Object Identifier (OID) Konzept für das Deutsche Gesundheitswesen, Gemeinschaftskonzept der HL7-Benutzergruppe in Deutschland e. V., Köln, der Arbeitsgemeinschaft Sciphox GbR mbH, Köln, der Kassenärztlichen Bundesvereinigung - Körperschaft des öffentlichen Rechts, Berlin, und des Deutschen Instituts für Medizinische Dokumentation und Information (DIMDI), Köln, Entwurf, Version 1.02, Stand: 18.03.2005 (www.hl7.de) \[dtcmetv3-hl7de\] HL7 Version 3 Datentypen und CMETs für das Deutsche Gesundheitswesen, www.hl7.de (Publikationen) \[ansicdar2\] HL7 v3 Clinical Document Architecture, Release 2.0 (ANSI Standard CDA Release 2, Juli 2005). \[XMLSig\] XML-Signature Syntax and Processing [2] \[SigG\] Gesetz über Rahmenbedingungen für elektronische Signaturen [3] \[SigV\] Verordnung zur digitalen Signatur http://bundesrecht.juris.de/sigv_2001/index.html

Internationale Spezifikationen allgemein und zu CDA Release 2

\[iherad\] IHE Radiology Technical Framework vol. 1 – Integration Profiles (SINR, XDS), 2005-08-15 \[hl7crs\] HL7 v3 , CDA Rel. 2 „ Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm)", 2005-11-17, 3rd normative ballot \[sci\] [www.sciphox.de-http://www.sciphox.de/], insbesondere „Working draft 15" \[ihepcc\] Use Cases for Medical Summaries, L. McNight, IHE PCC, 2005-09-08 \[ems\] e-MS. Clinical Document Architecture Implementation Guide Vancouver Island Health Authority, British Columbia (Level 2 und 3), 2004-12-17 \[volmed\] Guide d\’implémentation du Volet Médical au format CDA Release 2 – Niveau 3, 2005-09-01 \[ihelab\] IHE Laboratory Technical Framework, Supplement „Sharing Laboratory Reports (XDS-LAB)" vom 14. September 2006. http:// www.ihe.net

Klassifikationen / Terminologien

\[alphaid2006\] Die Identifikationsnummer des alphabetischen Verzeichnisses der ICD-10-GM-2006. Alphabet WHO, Diagnosethesaurus (OID 1.2.276.0.76.5.309) \[ops2006\] Operationen- und Prozedurenschluessel - Internationale Klassifikation der Prozeduren in der Medizin Version 2006; DIMDI, BMGS (OID 1.2.276.0.76.5.310) \[icd10gm2006\] Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme, 10. Revision, German Modification Version 2006; DIMDI, BMGS (OID 1.2.276.0.76.5.311) \[snomedct\] SNOMED Clinical Terms® (SNOMED CT®), universal health care terminology, www.snomed.org (OID 16.840.1.113883.6.96) \[idmacs\] Nomenklatur basierend auf dem Werk von Wingert F., Typ: komplette multi-axial generische Terminologie verknüpft zu einem medizinisch semantischen Netzwerk der Fa. ID, Berlin (OID 1.2.276.0.76.5.305) \[hl7mcg\] C Geßner: Kodierung von Einheiten physikalischer Messgrößen mit UCUM (Unified Code for Units of Measure). HL7 Mitteilungen 21/2006, 6-17. \[ucumau\] http://aurora.rg.iupui.edu/UCUM/ucum.html, http://aurora.regenstrief.org/UCUM/ \[ucumjamia\] Schadow G, McDonald CJ, Suico J, Föhring U, Tolxdorff T: Units of Measure in Clinical Information Systems. J Am Med Inform Assoc.1999; 6: 151-161. http://www.jamia.org/cgi/content/abstract/6/2/151

Konferenzen/Proceedings

\[cdaconf1\] First international conference on CDA, Berlin 2002. Konferenz-Website und Proceedings http://www.hl7.de/cda2002 \[cdaconf2\] Second International conference on CDA, Acapulco 2004. Konferenz-Website und Proceedings http://www.hl7.de/iamcda2004