Quelltext der Seite IG:Arztbrief 2006

<!--

    Implementierungsleitfaden "Arztbrief 2006"

-->
{{Infobox Dokument
|Title     Arztbrief 2006 auf Basis der<br/>HL7 Clinical Document Architecture Release 2<br/>für das deutsche Gesundheitswesen
|Short     = Arztbrief 2006
|Namespace = cdaab1
|Type      = Implementierungsleitfaden
|Version   = 1.5
|Submitted = .
|Date      = XX. XXXXXXXXX 2006
|Copyright = 2006
|Status    = Entwurf
|Period    = Entwurf
|OID       = n.n.
|Realm     = Deutschland
}}



{| 
| [[file:Cdaab1_vhitg_logo.jpg|200px|VHitG-Logo]] ||Initiative<br>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'''
{| class="hl7table"
|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.

[[file:Cdaab1_rim_basisklassen.gif|RIM Basisklassen]]
 
''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<sup> </sup>) 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.<sup> </sup>
CDA Release 2 als Fortentwicklung dieses Standards wurde, nach beinahe fünf Jahren weiterer Entwicklungsarbeit am Standard, im Juli 2005 zum ANSI Standard erhoben. In diese Entwicklungen sind zahlreiche Erfahrungen aus weltweit mehr als 15 größeren, teilweise nationenweiten Projekten eingeflossen, die sich intensiv um CDA Release 1 und der Weiterentwicklung verdient gemacht haben.
Basierend auf dem HL7 Referenz-Informationsmodell (siehe oben) besteht CDA Release 2, grob gesprochen, aus Tags / Markup, die Semantik bereitstellen für Personen und Dokumenteneigenschaften (z. B. <patient>, <provider>, <authenticator>, etc.) und für die Abbildung von Dokumentenstrukturen und -hierarchien genutzt werden können (z. B. <section>, <paragraph>, <table>, etc.).
Der Name für dieses Konzept änderte sich – aus der ursprünglichen Kona-Architektur wurde die Patient Record Architecture und dann schließlich die Clinical Document Architecture – aber die Ideen dieser Architektur sind gleich geblieben.
Ein wichtiges Konzept in CDA ist das der Level, die a.a.O. weiter erläutert werden (siehe 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.

[[file:Cdaab1_uebersicht.gif|Übersicht]]
 
''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.''

[[file:Cdaab1_xml_gesamt.png|600px|XML-Gesamtstruktur]]

''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 <nowiki><section></nowiki>
* Paragrafen <nowiki><paragraph></nowiki>
* Kennzeichnung von bestimmten Inhalten <nowiki><content></nowiki>
* Überschriften <nowiki><caption></nowiki>
* Tabellen <nowiki><table></nowiki>
* Listen <nowiki><list></nowiki>

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.

[[file:Cdaab1_auswahlliste.gif|Auswahlliste]]

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

[[file:Cdaab1_cda_rmim.jpg|CDA RMIM]]

''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)====
''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:''


{{BeginPurpleBox|Storyboard}}
Anamnese:

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

Befund:

Pricktest:
{{EndPurpleBox}}

<table>
<tr>
<td>Birke +++</td><td>Gräser-Mix +++</td><td>Hausstaubmilbe 1 +</td>
</tr>
<tr>
<td>Haselstrauch +++</td><td>Kammgras ++</td><td>Hausstaubmilbe 2 +</td>
</tr>
<tr>
<td>Erle +</td><td>Roggen ++</td><td>Schafwolle +</td>
</tr>
<tr>
<td>Hainbuche +</td><td>Quecke +</td><td>Rotbuche +</td>
</tr>
<tr>
<td>Eiche +</td>
</tr>
<tr>
<td colspan="3">''Keine Reaktion auf weitere Pollen, Katzen- / Hundehaare, Schimmelpilz.''</td>
</tr>
</table>

{|
|+
|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.''

{{BeginPurpleBox|Storyboard}}
Anamnese: 

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

Befund:

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

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

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

Diagnosen:

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

Röntgen:

Kernspintomographie der LWS:

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

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

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

3. In L 3/4 „bulging disc"

4. In den übrigen Etagen keine Besonderheiten

Fremdbefunde: -

Histologie: -

Verlauf: -

Entlassungsbefund:

Keine sensomotorischen Ausfälle

Prognose: -

Therapien:

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

Empfehlung: 

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

====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.''

{{BeginPurpleBox|Storyboard}}
Laborparameter: 

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

''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. 
 
[[file:Cdaab1_bildbeispiel.jpg|500px|Beispielbild]]


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.


<syntaxhighlight lang="xml">

<?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>
</syntaxhighlight>

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


[[file:Cdaab1_clindoc.gif|300px|Clinical Document]]

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

{| class="hl7table"
!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:

{| class="hl7table"
|+
!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:

<syntaxhighlight lang="xml">
<telecom nullFlavor="NASK"/>
</syntaxhighlight>

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:

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

<telecom nullFlavor="NASK"/>
</syntaxhighlight>

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

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


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

<syntaxhighlight lang="xml">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<id extension="13234453645" root="2.16.840.1.113883.2.6.15.3.427.1"/>
</syntaxhighlight>

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.

{| class="hl7table"
!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.

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


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

<syntaxhighlight lang="xml">
<title>Wiesenhof Klinik Entlassbrief</title>

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


==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.''

<syntaxhighlight lang="xml">
<effectiveTime value="200509241634"/>
</syntaxhighlight>


==Vertraulichkeit des Dokuments==
''confidentialityCode	Vertraulichkeitsgrad''
''CE CWE \[1..1\]''

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

{| class="hl7table"
|'''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.''

<syntaxhighlight lang="xml">
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<languageCode code="de-DE"/>
</syntaxhighlight>


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.

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

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

[[file:Cdaab1_pat_classes.gif|750px|Patient Classes]]
 
''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.''

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

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

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

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

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

====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..\*\]''

{{AttDesc
| ae = att
| rim = ent
| name = name
| desc = Name des Patienten
In diesem Attribut ist der Name des Patienten untergebracht.
| dt = 
| card = 0..*
| conf = 
}}


{{AttDesc
| ae = att
| rim = ent
| name = administrativeGenderCode	
| desc = Geschlecht
| dt = CE CWE <= AdministrativeGender
| card = 0..1
| conf = 
}}



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.

{|class="hl7table"
!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)''

{{AttDesc
| ae = att
| rim = ent
| name = birthTime 	
| desc = Geburtsdatum
| dt = TS
| card = 0..1
| conf = 
}}

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.

{{AttDesc
| ae = att
| rim = ent
| name = id
| desc = ID der Heilberufler-Organisation
| dt = II
| card = 0..*
| conf = 
}}

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.

<syntaxhighlight lang="xml">
<id extension="175648374" root="1.2.276.0.76.4.5"/>
</syntaxhighlight>



{{AttDesc
| ae = att
| rim = ent
| name = name	
| desc = Name der Heilberufler-Organisation
| dt = ON
| card = 0..*
| conf = 
}}

Der Name der Heilberufler-Organisation muss hier angegeben werden.

<syntaxhighlight lang="xml">
<name>Wohlsein Krankhaus</name>
</syntaxhighlight>

{{AttDesc
| ae = att
| rim = ent
| name = telecom	
| desc = Telekommunikation-Kontakte
| dt = TEL
| card = 0..*
| conf = 
}}


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

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


{{AttDesc
| ae = att
| rim = ent
| name = addr
| desc = Adresse der Heilberufler-Organisation
| dt = AD
| card = 0..*
| conf = 
}}

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

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

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

====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.
 
[[file:Cdaab1_birth_palce.jpg|300px|Birth Place]]

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

{{AttDesc
| ae = att
| rim = ent
| name = name	
| desc = Name des Geburtsorts
| dt = EN
| card = 0..1
| conf = 
}}


{{AttDesc
| ae = att
| rim = ent
| name = addr
| desc = Adressinformationen zum Geburtsort
| dt = AD
| card = 0..1
| conf = 
}}

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

====Sprachfertigkeiten des Patienten====

{{AttDesc
| ae = elm
| rim = LanguageCommunication
| name = languageCommunication
| desc =  Diese Klasse gibt die Sprachfertigkeiten des Patienten wieder. 
| dt = 
| card = 0..*
| conf = 
}}


{{FAQBox|Diese Information wird in diesem Leitfaden zunächst nicht verwendet.}}

====Vormundschaft für den Patienten (Guardian)====

{{AttDesc
| ae = elm
| rim = Guardian
| name = Guardian
| desc =  In der Klasse ''Guardian'' kann über Vormundschaften für den Patienten Auskunft gegeben werden. 
| dt = 
| card = 0..*
| conf = 
}}

{{FAQBox|Diese Information wird in diesem Leitfaden zunächst nicht verwendet.}}

===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.
 
[[file:Cdaab1_autor.gif|500px|Autor]]

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

<syntaxhighlight lang="xml">
<id extension="190388km89" root="2.16.840.1.113883.3.24535"/>
</syntaxhighlight>


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

{{AttDesc
| ae = att
| rim = ent
| name = id
| desc = ID der Organisation
| dt = II
| card = 0..*
| conf = 
}}

{{AttDesc
| ae = att
| rim = ent
| name = name
| desc = Name der Organisation
| dt = ON
| card = 0..*
| conf = 
}}

{{AttDesc
| ae = att
| rim = ent
| name = telecom
| desc = Telekommunikation-Kontakte
| dt = TEL
| card = 0..*
| conf = 
}}

{{AttDesc
| ae = att
| rim = ent
| name = addr
| desc = Adresse der Organisation
| dt = AD
| card = 0..*
| conf = 
}}

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

<syntaxhighlight lang="xml">
<author>
    <time value="20050829"/>
    <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>
</syntaxhighlight>

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

[[file:Cdaab1_custodian.gif|500px|Custodian]]

''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\]''

<syntaxhighlight lang="xml">
|'''<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>'''
</syntaxhighlight>

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

[[file:Cdaab1_inf_recipient.gif|600px|Information Recipient]]

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

{| class="hl7table"
|+
!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.''


<syntaxhighlight lang="xml">
|'''<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>'''
</syntaxhighlight>

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

{| class="hl7table"
|+
!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''

[[file:Cdaab1_authenticator.gif|600px|Legal Authenticator]]
 
''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.

[[file:Cdaab1_participants.gif|600px|Participants]]

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

{| class="hl7table"
|+
!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.

{| class="hl7table"
|'''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.

{| class="hl7table"
| ||'''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).''

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>


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

[[file:Cdaab1_related_doc.gif|600px|related Document]]

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

{| class="hl7table"
|+
!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. 
 
[[file:Cdaab1_doc_relations.gif|600px|Document Relations]]

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


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

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

[[file:Cdaab1_encompassing_enctr.gif|600px|Encompassing Encounter]]

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

{| class="hl7table"
|+
!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.''

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

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

[[file:Cdaab1_consent.jpg|500px|Consent]]

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
    <component>
        <structuredBody>
              ... CDA R2 Body
        </structuredBody>
   </component>
</ClinicalDocument>
</syntaxhighlight>


==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\]''

[[file:Cdaab1_section.jpg|500px|Section]]

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

[[file:Cdaab1_body.gif|600px|Body]]

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

[[file:Cdaab1_section_lvl1.gif|500px|Section Level1]]

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.

[[file:Cdaab1_section_lvl2.gif|500px|Section Level2]]


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.

[[file:Cdaab1_section_lvl3.gif|500px|Section Level3]]


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.

[[file:Cdaab1_section_comp.gif|500px|Section Components]]


''Abbildung 20: Eine section Komponente besteht aus einem &lt;code\&gt;, der den Abschnitt typisiert, sowie einer Überschrift im \<title\>. Im obligato¬rischen &lt;text&gt; 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.


{| class="hl7table"
!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.''

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

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

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

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.

<syntaxhighlight lang="xml">
<component>
  <structuredBody>
  ... 
    <component>
      <section>
        <code code=... codeSystem=... />
        <title> ... </title>
        <text>
           ...
        </text>
      </section>
    </component>
    ...
  </structuredBody>
</component>
</syntaxhighlight>

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:

<syntaxhighlight lang="xml">
<list>
  <item> 1. Element der Liste</item>
  <item> 2. Element der Liste</item>
  <item> ...</item>
  <item> n. Element der Liste</item>
</list>
</syntaxhighlight>

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


<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

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

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

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

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

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.

<syntaxhighlight lang="xml">
<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th> 
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  ...
</table>
</syntaxhighlight>

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:

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>


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

[[file:Cdaab1_beispiel2.gif|600px|Beispiel]]

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

===Ü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).''

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

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 &lt;br/&gt; 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''

<syntaxhighlight lang="xml">
<text>
  Patient hat Asthma seit seinem zehnten Lebensjahr.<br/>
  Patient kommt damit gut zurecht.
</text>
</syntaxhighlight>

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

[[file:Cdaab1_obs_media.gif|500px|Observation Media]]

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

{| class="hl7table"
!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) \[http://www.cdrom.com/pub/png\] 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.''

<syntaxhighlight lang="xml">
<section>
   <code code="8709-8" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Untersuchung der Haut</title>
   <text>Rötung an der Palmarfläche des linken Zeigefingers
     <renderMultiMedia referencedObject="MM1"/>
   </text>
   <entry>
      <observationMedia classCode="OBS" moodCode="EVN" 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>
</syntaxhighlight>

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

{| class="hl7table"
|+
!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''

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

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

{| class="hl7table"
!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.'' ''

<syntaxhighlight lang="xml">
<component>
  <structuredBody>
  ... 
    <component>
      <section>
        <code code=... codeSystem=... />
        <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>
</syntaxhighlight>

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.

{| class="hl7table"
!Gebrauch einer ID!!Referenz einer ID
|-
|<list><br>  <item ID="iii">List item 1</item><br></list>
||<code ...<br>  <originalText><br>    <reference value="\#iii"/><br>  </originalText> ...
|-
|<tr ID="aaa"><br>  <td ID="bbb">Tabellenzelle 1</td><br>  <td>Tabellenzelle 2</td></tr>
||<code ...<br><originalText><br>   <reference value="\#aaa"/><br>  </originalText><br>...
<code ...<br>  <originalText><br>    <reference value="\#bbb"/><br>  </originalText> ...
|-
|<paragraph ID="pp-1"><br>Text</paragraph>
||<originalText><br> <reference value="\#pp-1"/><br></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.

{| class="hl7table"
|+
!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.

[[file:Cdaab1_section_participants.gif|600px|Participants]]

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

[[file:Cdaab1_entry_relationship.jpg|600px|Entry Relationship]]

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

<syntaxhighlight lang="xml">
<component>  <!-- Anrede -->
  <section>
    <code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" />
    <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>
</syntaxhighlight>

{{NoteBox|
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.

<syntaxhighlight lang="xml">
<component>  <!-- Fragestellung -->
  <section>
    <code code="X-RFR" codeSystem="2.16.840.1.113883.6.1" />
    <title>Grund der Überweisung</title>
    <text>Röntgen Thorax in zwei Ebenen</text>
  </section>
</component>
</syntaxhighlight>

{{NoteBox|
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:

{|class="hl7table"
|+
!Angaben flach (ohne Substrukturen)!!Angaben strukturiert
|-
|Eigenanamnese<br>
Allgemeine Anamnese<br>
Frühere Krankheiten<br>
Frühere Operationen<br>
Fachspezifische Anamnese<br>
Psychosoziale Anamnese<br>
Familienanamnese<br>
Fremdanamnese<br>
Immunisierungen<br>
Medikamentenanamnese<br>
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.

<syntaxhighlight lang="xml">
<component>
  <!-- Anamnese Komponente -->
  <section>
    <code code="10164-2"
          codeSystem="2.16.840.1.113883.6.1"
          codeSystemName="LOINC"/>
    <title>Anamnese</title>
    <text>
       Seit Jahren wiederholt chronische Bronchitiden 
       besonders bei kalter Luft. Bei Anstrengung 
       expiratorische Atemnot. Kontakt mit Haustieren.
    </text>
  </section>
</component>
</syntaxhighlight>

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

{| class="hl7table"
|+
!Angaben flach (ohne Substrukturen)!!Angaben strukturiert
|-
|Fremdbefund<br>
Laborwerte<br>
Histologiebefund<br>
Biopsiebefund<br>
Radiologiebefund<br>
Pathologiebefund<br>
Kardiologiebefund<br>
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.

<syntaxhighlight lang="xml">
<component>                     <!-- Befund Komponente -->
  <section>
    <code code="10210-3" codeSystem="2.16.840.1.113883.6.1"
          codeSystemName="LOINC"/>
    <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>
</syntaxhighlight>

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

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


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

[[file:Cdaab1_observation.gif|250px|Observation]]

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

{{AttDesc
| ae = att
| rim = act
| name = moodCode	
| desc = Mood-Code <= EVN
| dt = 
| card = 
| conf = 
}}

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

{{AttDesc
| ae = att
| rim = act
| name = id	
| desc = Diagnosen-Identifikationsnummer
| dt = SET<II>
| card = 0..*
| conf = 
}}

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.

{{AttDesc
| ae = att
| rim = act
| name = code	
| desc = Diagnose-Klassifizierung (Diagnosetyp)
| dt = CD CWE
| card = 1..1
| conf = 
}}

Hiermit wird der Typ der Diagnose, z. B. Aufnahmediagnose etc. spezifiziert (siehe unten).

{{AttDesc
| ae = att
| rim = act
| name = negationInd	
| desc = Negations-Indikator
| dt = BL
| card = 
| conf = 
}}

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

{{AttDesc
| ae = att
| rim = act
| name = text	
| desc = ergänzende Erläuterungen zur Diagnose
| dt = ED
| card = 0..1
| conf = 
}}

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.


{{AttDesc
| ae = att
| rim = act
| name = statusCode	
| desc = Statuscode <= completed
| dt = 
| card = 
| conf = 
}}


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.

{{AttDesc
| ae = att
| rim = act
| name = effectiveTime	
| desc = Zeitangabe Diagnose
| dt = IVL<TS>
| card = 0..1
| conf = 
}}

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.

{{AttDesc
| ae = att
| rim = act
| name = value	
| desc = Diagnose-Code
| dt = CD
| card = 0..1
| conf = M
}}

Hier wird die eigentliche Diagnose codiert angegeben. Im Rahmen dieses Leitfadens ist die Diagnose mindestens als ICD 10 Code anzugeben.

{{ConstraintBox|
Regel DGCD: Verpflichtend bei den Diagnosen sind das ''@code'' Attribut und die Angabe zum Codesystem (OID) in ''@codeSystem''.
}}

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

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.

[[file:Cdaab1_levels.gif|500px|Levels]]

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

<syntaxhighlight lang="xml">
<effectiveTime>
  <low value="20050825"/>
</effectiveTime>
</syntaxhighlight>


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

{| class="hl7table"
!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)''

{{NoteBox|
''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.

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


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

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


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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight >

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight >

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

{| class="hl7table"
|+
!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)''

<syntaxhighlight lang="xml">
|'''<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>'''
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
|'''<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>'''
</syntaxhighlight>

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

{| class="hl7table"
|+
!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)''

<syntaxhighlight lang="xml">
|'''<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>'''
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>

====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.''

<syntaxhighlight lang="xml">
|'''<component>'''
'''  <!-- Diagnose mit ICD Komponente -->'''
'''  <section>'''
'''    <code code="11535-2" codeSystem="2.16.840.1.113883.6.1"/>'''
'''    <title>Diagnosen mit ICD 10</title>'''
'''    <text>'''
'''      <table border="1">'''
'''        <thead>'''
'''          <tr>'''
'''            <th>Diagnose</th>'''
'''            <th>ICD Code</th>'''
'''            <th>Lokalisation</th>'''
'''            <th>Zusatz</th>'''
'''          </tr>'''
'''        </thead>'''
'''        <tbody>'''
'''          <tr>'''
'''            <th>'''
'''              <content ID="diag-1">'''
'''                Bösartige Neubildung des Hodens'''
'''              </content>'''
'''            </th>'''
'''            <th>C62.9</th>'''
'''            <th>L</th>'''
'''            <th>G</th>'''
'''          </tr>'''
'''        </tbody>'''
'''      </table>'''
'''    </text>'''
'''    <entry>'''
'''      <observation classCode="OBS" moodCode="EVN">'''
'''        <code code="DISDX" codeSystem="2.16.840.1.113883.3.7.1.50"'''
'''              codeSystemName="LOINC" displayName="Entlass-Diagnose"/>'''
'''        <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>'''
'''            <code xsi:type="CD" nullFlavor="UNK"/>'''
'''            <value xsi:type="ED">bevorstehende Geschlechtsumwandlung, '''
'''               \’amtliches\’ Geschlecht bereits weiblich,'''
'''               Operation steht jedoch noch aus </value>'''
'''          </observation>'''
'''        </entryRelationship>'''
'''      </observation>'''
'''    </entry>'''
'''  </section>'''
'''</component>'''
</syntaxhighlight>

===Besondere Hinweise (Cave)===
In dem Abschnitt CAVE werden 
* Hinweise zu Risikofaktoren beim Patienten
* Allergien
abgebildet.

<syntaxhighlight lang="xml">
|'''<component>     <!-- Cave Komponente : Bsp. einer Medikamentenallergie--> '''
'''  <section>'''
'''    <code code="11382-9" codeSystem="2.16.840.1.113883.6.1" 
          codeSystemName="LOINC"/>'''
'''    <text>Penicilinallergie</text>'''
'''  </section>'''
'''</component>'''
</syntaxhighlight>

===Therapien/Behandlungsmaßnahmen===
In dem Abschnitt Therapie werden u. a.
* Medikamente
* Fachspezifische Eingriffe
* Operationen
* Strahlentherapie
* Lichttherapie
* Psychiatrische Therapie
abgebildet.

<syntaxhighlight lang="xml">
<component>                     <!-- Therapien Komponente --> 
  <section>
    <code code="19009-0" codeSystem="2.16.840.1.113883.6.1" 
          codeSystemName="LOINC"/>
    <title>Therapien – Jetzige Medikation</title>
    <text>Atemur morgens 2x und abends 2x</text>
  </section>
</component>
</syntaxhighlight >

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.
 
[[file:Cdaab1_procedure.gif|400px|Procedure]]

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

<syntaxhighlight lang="xml">
<code code="1-697.7" codeSystem="1.2.276.0.76.5.310"
      codeSystemName="ops2006"/>
</syntaxhighlight>

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.

{{NoteBox|
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. 
}}

{{AttDesc
| ae = att
| rim = act
| name = text	
| desc = ergänzende Erläuterungen zur Prozedur
| dt = ED
| card = 0..1
| conf = 
}}

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.

{{AttDesc
| ae = att
| rim = act
| name = statusCode	
| desc = Statuscode <= completed
| dt = 
| card = 
| conf = 
}}

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


{{AttDesc
| ae = att
| rim = act
| name = effectiveTime	
| desc = Zeitangabe Prozedur
| dt = IVL<TS>
| card = 0..1
| conf = 
}}

Zeitangaben, von wann an (bis wann) die Prozedur durchgeführt wurde. Dies ist in der Regel ein Zeitpunkt.

{{AttDesc
| ae = att
| rim = act
| name = methodCode	
| desc = Klassifizierung der Methode
| dt = SET<CE>
| card = 0..*
| conf = 
}}

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.

{{AttDesc
| ae = att
| rim = act
| name = approachSiteCode	
| desc = Klassifizierung der Zugangsmethode
| dt = SET<CD>
| card = 0..*
| conf = 
}}

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.

{{AttDesc
| ae = att
| rim = act
| name = targetSiteCode	
| desc = Klassifizierung des Zielgebiets
| dt = SET<CD> CWE
| card = 0..*
| conf = 
}}

Der anatomische Situs oder das System, auf das die Behandlungsmaßnahme abzielt. Dieses Klassenattribut wird im Rahmen dieses Leitfadens zunächst nicht verwendet.

<syntaxhighlight lang="xml">
<component>
  <section>
    <code code="29554-3" codeSystem="2.16.840.1.113883.6.1" 
          codeSystemName="LOINC"/>
    <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">
        <code code="3-00d" codeSystem="1.2.276.0.76.5.310" 
              codeSystemName="ops2006">
          <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>
        </code>
        <statusCode code="completed"/>
        <effectiveTime value="200511241517"/>
      </procedure>
    </entry>
  </section>
</component>
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
<component>
  <section>
        <title>Notizen</title>
    <text>
             ....
    </text>
  </section>
</component>
</syntaxhighlight >

===Epikrise===
In dem Abschnitt Epikrise werden 
* der zusammenfassende Rückblick
* die Empfehlung
* die Prognose
abgebildet.


<syntaxhighlight lang="xml">
|'''<component>        <!—Epikrise Komponente am Beispiel einer Empfehlung --> '''
'''  <section>'''
'''    <code code="X-EPICR" codeSystem="2.16.840.1.113883.6.1" '''
'''          codeSystemName="LOINC"/>'''
'''    <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>'''
</syntaxhighlight>

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

<syntaxhighlight lang="xml">
|'''<component>        <!-- Anhänge --> '''
'''  <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>'''
</syntaxhighlight >

===Schlusstext===
Der Schlusstext eines Arztbriefes wird in diesem Abschnitt abgebildet.

<syntaxhighlight lang="xml">
|'''<component>        <!-- Schlusstext --> '''
'''  <section>'''
'''    <text>  Mit freundlichen, kollegialen Grüßen  </text>'''
'''  </section>'''
'''</component>'''
</syntaxhighlight >

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

[[file:Cdaab1_external_doc.jpg|600px|External Document]]

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

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


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.

==LOINC Codes für Laborbefunde==

==Gebräuchliche UCUM Einheiten für Laborbefunde==

 

=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".

{{AlertBox|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.

[[file:Cdaab1_interaktionsmodell.gif|700px|Interaktionsmodell]]

''''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.<br>
http://www.w3.org/TR/xmlschema-0/<br>
http://www.w3.org/TR/xmlschema-1/<br>
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
[http://www.w3.org/TR/2002/REC-xmldsig-core-20020212-http://www.w3.org/TR/2002/REC-xmldsig-core-20020212]
|-
|\[SigG\]
||Gesetz über Rahmenbedingungen für elektronische Signaturen 
[http://bundesrecht.juris.de/sigg_2001/index.html-http://bundesrecht.juris.de/sigg_2001/index.html]
|-
|\[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
|}