elga-cdaalf-2.06.2:Allgemeiner Aufbau des CDA Body

1 Allgemeiner Aufbau des CDA Body

Der CDA Body eines CDA-Dokuments kann entweder „strukturiert“ oder „unstrukturiert“ angegeben werden.

1.1 Unstrukturierter medizinischer Inhalt: nonXMLBody

Diese Art des CDA Body dient dazu, medizinische Inhalte völlig unstrukturiert anzugeben. Dies erfolgt in einem text-Element, wobei der Inhalt dieses Elements auch ein eingebettetes Dokument, beispielsweise PDF, codiert in Base64 sein kann.
Welche Art von Inhalt in dem text-Element abgebildet ist, wird über die Attribute @mediaType und @representation festgelegt.

1.1.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
   CDA Header
   :
   <component>
     <!-- Unstrukturierter CDA Body (Non-XML) -->
     <nonXMLBody>
       <text mediaType="application/pdf" representation="B64">
          :
       </text>
     </nonXMLBody>
   </component>
</ClinicalDocument>

1.2 Strukturierter medizinischer Inhalt: structuredBody

Der structuredBody eines CDA Release 2.0 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.

1.2.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
   CDA Header
   :
   <component>
      <!-- strukturierter CDA Body -->
      <structuredBody>
         :
        <component>
           <section>
             … CDA Body Sektion …
           </section>
        </component>
         :
      </structuredBody>
   </component>
</ClinicalDocument>

1.2.2 CDA Level 1 bis 3

Die CDA Level repräsentieren die unterschiedliche Feinheit (Granularität) der wiedergegebenen klinischen Informationen und des maschinenauswertbaren Markups (standardisierte Form der maschinenauswertbaren Auszeichnung von Text).

1.2.2.1 CDA Level 1

Mit Level 1 ist ein XML Dokument gekennzeichnet, das vor allem auf „menschliche Interoperabilität“ abzielt („human readable“), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann, zum Beispiel durch Stylesheets. Es gibt keine Einschränkungen den Gebrauch oder Zweck des Dokuments oder den Inhalt betreffend. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der reinen Papierwelt bekannt ist.

CDA Level 1 sind alle Dokumente mit einem CDA „nonXMLBody“ und jene mit Sektionen ohne Codierung:

<section>
   <title>Aufnahmegrund</title>
   <text>
	… Medizinischer Text …
   </text>
</section>

1.2.2.2 CDA Level 2

Im Level 2 werden die Abschnitte klassifiziert. Die Identifikation dieser Abschnitte ist auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird durch die Assoziation des Abschnitts mit einem Code erreicht. Als Codierung der Sektionen kann prinzipiell jedes Codesystem, vorzugsweise aber LOINC herangezogen werden.

Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinenauswertbar, 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 Entlassungsbrief beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein Befundbericht ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann.

<section>
  <code
     code="42349-1"
     displayName="Grund für die Überweisung/Einweisung"
     codeSystem="2.16.840.1.113883.6.1"
     codeSystemName="LOINC" />
     <title>Aufnahmegrund</title>
     <text>
	… Medizinischer Text …
     </text>
</section>

1.2.2.3 CDA Level 3

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich zu der lesbaren Text-Sektion auf dem Niveau von Einzelinformationen maschinenauswertbare 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.

Alle relevanten medizinischen Daten MÜSSEN im „menschenlesbaren Teil“, dem narrativen Block (title und text-Elemente der Sections) enthalten sein [R]. Die maschinenlesbaren Einträge (entry) MÜSSEN inhaltlich konsistent zum lesbaren Textbereich sein und sollen zusätzlich die entsprechenden Inhaltsstellen im Textbereich referenzieren. Zusätzliche maschinenlesbare Informationen können angegeben werden, sofern sie nicht dargestellt werden müssen und auch nicht Bestandteil des signierten Originalbefundes sind. Sind die narrativen Daten direkt von den maschinenlesbaren abgeleitet und daher inhaltlich gleich, wird das im Entry durch das Attribut typeCode="DRIV" angegeben. Hier kann ausschließlich der maschinenlesbare Teil ohne Informationsverlust zur Weiterverarbeitung verwendet werden.

<section>
   <code
     code="42349-1"
     displayName="Grund für die Überweisung/Einweisung"
     codeSystem="2.16.840.1.113883.6.1"
     codeSystemName="LOINC" />
     <title>Aufnahmegrund</title>
     <text>
	… Medizinischer Text …
     </text>
     <entry>
        … HL7 Version 3 RIM Klassen (Beobachtung, Prozedur, …) mit Codes …
     </entry>
</section>

1.3 Sektionen

CDA bietet die Möglichkeit Sektionen mit sogenannten „templateId“-Elementen zu versehen. Mit diesen Elementen ist es möglich, analog zur ELGA Implementierungsleitfaden-Kennzeichnung für das gesamte Dokument, auch einzelne Sektionen zu kennzeichnen.

Diese Kennzeichnung ist speziell für Prüfmittel (z.B.: Schematron) wichtig, da über diese Kennzeichnungen die zugrundeliegenden Regeln zur Befüllung der Sektion zugeordnet und abgeprüft werden können.

Verweis auf speziellen Implementierungsleitfaden:
Welche templateId angegeben werden muss, ist im entsprechenden speziellen Implementierungsleitfaden in der Definition der Sektionen beschrieben.

1.3.1 Spezifikation

Id	1.2.40.0.34.11.30001 ref elgabbr-	Gültigkeit	2011‑12‑19
Status	Aktiv	Versions-Label
Name	BodySection	Bezeichnung	BodySection
Beschreibung CDA bietet die Möglichkeit Sektionen mit sogenannten „templateId“-Elementen zu versehen. Mit diesen Elementen ist es möglich, analog zur ELGA Implementierungsleitfaden-Kennzeichnung für das gesamte Dokument, auch einzelne Sektionen zu kennzeichnen. Diese Kennzeichnung ist speziell für Prüfmittel (z.B.: Schematron) wichtig, da über diese Kennzeichnungen die zugrundeliegenden Regeln zur Befüllung der Sektion zugeordnet und abgeprüft werden können.
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.40.0.34.11.90004 Inklusion AuthorElements DYNAMIC
Beziehung	Version: Template 1.2.40.0.34.11.30001 BodySection (2011‑12‑19) ref elgabbr-
Beispiel	Strukturbeispiel <hl7:ClinicalDocument>    : CDA Header :   <hl7:component>     <!-- strukturierter CDA Body -->     <hl7:structuredBody>       <hl7:component>         <hl7:section>           <hl7:templateId root="1.2.3.4.5.6.7.8"/>          <hl7:code/>          <hl7:title>Name der Sektion</hl7:title>           : … CDA Body Sektion …         </hl7:section>      </hl7:component>    </hl7:structuredBody>  </hl7:component></hl7:ClinicalDocument>
Item DT Kard Konf Beschreibung Label hl7:templateId II 0 … * Templateidentifikation(en) der Sektion. (Bod...ion) hl7:id II 0 … 1 Eindeutige ID der Sektion (optional). (Bod...ion) hl7:code CE 0 … 1 Code der Sektion. (Bod...ion) hl7:title ST 0 … 1 Titel der Sektion. (Bod...ion) hl7:text 1 … 1 R Information für den menschlichen Leser. (Bod...ion) Eingefügt 0 … * von 1.2.40.0.34.11.90004 AuthorElements (DYNAMIC) Auswahl 0 … * Elemente in der Auswahl: hl7:author[not(@nullFlavor)] hl7:author[@nullFlavor] hl7:author Verfasser des Dokuments. (Bod...ion) wo [not(@nullFlavor)] @typeCode cs 0 … 1 F AUT @context​Control​Code cs 0 … 1 F OP hl7:functionCode CE 0 … 1 Funktionscode des Verfassers des Dokuments z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, … Eigene Codes und Bezeichnungen können verwendet werden.  Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen. (Bod...ion) hl7:time TS.​DATE.​MIN 1 … 1 R Der Zeitpunkt an dem das Dokument verfasst wurde.Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Zugelassene nullFlavor: UNK (Bod...ion) hl7:assignedAuthor 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. (Bod...ion) @classCode cs 0 … 1 F ASSIGNED   Beispiel <assignedAuthor classCode="ASSIGNED">   <id extension="ied8984938" root="1.2.276.0.76.3.1.139.933"/>  <assignedPerson classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </assignedPerson></assignedAuthor> hl7:id II 1 … * R Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. (Bod...ion) hl7:code CE 0 … 1 Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung)z.B: „Facharzt/Fachärzting für Gynäkologie“, Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben. Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen. (Bod...ion)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (Bod...ion) Auswahl 1 … 1 Elemente in der Auswahl: hl7:assigned​Person hl7:assigned​Authoring​Device hl7:assigned​Person  … 1 Personendaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen. (Bod...ion) Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE hl7:name PN 1 … 1 M Name der Person Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden! Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen. (Bod...ion) hl7:assigned​Authoring​Device  … 1 (Bod...ion) @classCode cs 0 … 1 F DEV @determiner​Code cs 0 … 1 F INSTANCE hl7:manufacturer​Model​Name SC 0 … 1 Hersteller und Modellbezeichnung des datenerstellenden Gerätes. (Bod...ion) hl7:softwareName SC 0 … 1 Bezeichnung (und ggf Version) der datenerstellenden Software. (Bod...ion) hl7:represented​Organization 1 … 1 M (Bod...ion) Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Bod...ion) hl7:name ON 1 … 1 M (Bod...ion) hl7:telecom TEL.AT 0 … * (Bod...ion) hl7:addr AD 0 … 1 (Bod...ion) hl7:author Verfasser nicht bekannt/nicht anwendbar (Bod...ion) wo [@nullFlavor] @nullFlavor cs 1 … 1 F NA   Beispiel <author nullFlavor="NA">   <time nullFlavor="NA"/>  <assignedAuthor nullFlavor="NA">     <id nullFlavor="NA"/>  </assignedAuthor></author> hl7:time 1 … 1 R (Bod...ion) @nullFlavor cs 1 … 1 F NA hl7:assignedAuthor 1 … 1 R (Bod...ion) @nullFlavor cs 1 … 1 F NA hl7:id 1 … 1 R (Bod...ion) @nullFlavor cs 1 … 1 F NA hl7:entry 0 … * Maschinenlesbare Elemente der Sektion. (Bod...ion)

1.4 Textstrukturierung

Die medizinischen Informationen werden im CDA Body immer in Textform wiedergegeben (der „narrative Block“ ist verpflichtend). Dies garantiert, dass die Dokumente immer für den Menschen lesbar (und verstehbar) sind.

Der Text selber kann wiederum Strukturelemente aufweisen. Dies kann genutzt werden, um Listen, Tabellen oder auch Unterabschnitte zu definieren.

Der CDA-Standard erlaubt nur eine kleine Auswahl an Formatierungsoptionen für den narrativen Block, damit die oben genannte einfache Lesbarkeit („human readability“) zuverlässig erhalten bleibt und die Anforderungen für die Wiedergabe einfach bleiben.

Dieses Kapitel behandelt die verschiedenen Möglichkeiten der Textstrukturierung im text-Element einer CDA Sektion.

Hinweis: Damit die Textstrukturierung möglichst von allen im Umlauf befindlichen Style-sheets korrekt wiedergegeben kann, dürfen nur bekannte Formatierungsoptionen verwendet werden.
Nur die in diesem Leitfaden genannten Optionen für die Strukturierung des Textes im narrativen Block sind ERLAUBT, alle anderen daher VERBOTEN.

Innerhalb eines Section-Tags wird in CDA Level 2 das <text>-Element verwendet, um den narrativen Text („plain text“) darzustellen. In vielen Fällen lassen sich die medizinischen Inhalte aber auch noch weitergehend 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.

1.4.1 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=“unordered“), die üblicherweise mit Bulletpoints • dargestellt wird, und in sortierter Form (@listType=“ordered“), 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.

Folgende styleCodes können für die Formatierung von Listen mittels Aufzählungspunkten verwendet werden:

styleCode	Definition	Nutzungsbeispiel
Disc	Unsortierte Liste mit ausgefüllten Kreisen	<list listType="unordered" styleCode= "Disc">
Circle	Unsortierte Liste mit nicht ausgefüllten Kreisen	<list listType="unordered" styleCode= "Circle">
Square	Unsortierte Liste mit ausgefüllten Quadraten	<list listType="unordered" styleCode= "Square">
Arabic	Sortierte Liste mit Zahlen (1, 2, 3)	<list listType="ordered" styleCode= ”Arabic">
LittleRoman	Sortierte Liste mit kleingeschriebenen römischen Zahlen (i, ii, iii)	<list listType="ordered" styleCode= ”LittleRoman">
BigRoman	Sortierte Liste mit großgeschriebenen römischen Zahlen (I, II, III)	<list listType="ordered" styleCode= ”BigRoman">
LittleAlpha	Sortierte Liste mit kleingeschriebenen Buchstaben (a, b, c)	<list listType="ordered" styleCode= ”LittleAlpha">
BigAlpha	Sortierte Liste mit großgeschriebenen Buchstaben (A, B, C)	<list listType="ordered" styleCode= ”BigAlpha">
None	Unterdrückt die Ausgabe von Aufzählungszeichen9	<list styleCode= "none">

⁹ Kann verwendet werden, um eine Tabelle in einem Tabellenfeld einzufügen. Dabei wird ein List-Item im <td> -Element eingefügt, darin kann eine Tabelle als Unterelement angegeben werden.

1.4.1.1 Strukturbeispiel

Eine Liste hat das folgende Aussehen:

<text>
   :
   <list listType="ordered" styleCode= ”BigAlpha">
     <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>

1.4.2 Tabellen

Zur Repräsentation medizinischer Inhalte, die sich adäquat tabellarisch darstellen lassen, bietet sich die Tabellenform an. Als Beispiele seien genannt: Laborwerte, Allergiewerte, Diagnosen mit ICD-Codierung etc.

CDA realisiert ein vereinfachtes XHTML Table Modell, das HTML sehr ähnelt. Eine Tabelle wird mit dem table-Element angegeben. Siehe auch Erweiterte styleCodes.

Die Tabellenüberschrift wird eingeschlossen in thead Tags, die Überschriftenzeile in tr Tags und die einzelnen Spalten-Items der Überschrift mit th Tags.

Die optionale Tabellenunterschrift <tfoot> wird entsprechend der HTML-Tabellenkonvention direkt vor dem <tbody>-Tag und nach dem <thead> Tag angeführt. Es wird für Fußnoten in Tabellen verwendet und enthält genau einen <tr> und einen <td>-Tag (Siehe auch Beispiel in Fußnoten)

Die eigentlichen Tabelleninhalte werden in tbody Tags, die Datenzeile in tr Tags und die einzelnen Spalteninhalte einer Datenzeile mit td Tag gekapselt.

Die Vorgaben für Tabellen MÜSSEN korrekt eingehalten werden, damit sie zuverlässig und korrekt durch Stylesheets dargestellt werden können. Die Anzahl der Spalten MUSS über eine komplette Tabelle in thead und tbody gleich bleiben (ausgenommen tfoot).

1.4.2.1 Strukturbeispiel

Eine Tabelle hat das folgende Aussehen:

<text>
   :
   <table>
     <!-- Kopfzeile -->
     <thead>
       <tr>
          <th>Spaltenüberschrift 1</th>
          <th>Spaltenüberschrift 2</th>
       </tr>
     </thead>

     <!-- Optionale Fußzeile mit EINER Spalte -->
     <tfoot>
	<tr>
		<td>Die Fußzeile hat eine durchgehende Spalte</td>
	</tr>
     </tfoot>

     <!-- Tabelleninhalte - Anzahl der Spalten gleich wie Kopfzeile -->
     <tbody>
       <tr>
         <td>1. Zeile - Daten der Spalte 1</td>
         <td>1. Zeile - Daten der Spalte 2</td>
       </tr>
       <tr>
         <td>n. Zeile - Daten der Spalte 1</td>
         <td>n. Zeile - Daten der Spalte 2</td>
       </tr>
     </tbody>
   </table>
   :
</text>

1.4.3 Unterabschnitte

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

1.4.3.1 Strukturbeispiel

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

1.4.4 Referenzierter bzw. Attribuierter 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.

Referenzierter Inhalt
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) wiederfindet, kann sich somit explizit auf die vom content-Element im Textteil umschlossene Information beziehen.

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

1.4.4.1 Zugelassene styleCode Attribut-Werte

styleCode	Definition	Nutzungsbeispiel
bold	Fettdruck	<content styleCode="bold"> text </content>
underline	Unterstrichen	<content styleCode="underline"> text </content>
italics	Kursivschrift	<content styleCode="italics"> text </content>
emphasis	Kapitälchen	<content styleCode="emphasis"> text </content>

1.4.4.2 Strukturbeispiel

Im folgenden 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 (siehe „Zusammenhang Text und Entry“).

Darunter findet sich ein Text, der fett gedruckt erscheinen soll.

<text>
   :
   Diagnose des Patienten: <content ID="diag1">Asthma</content>
   <content styleCode="bold">Dieser Text ist fettgedruckt.</content>
   <content styleCode="bold italics"> Text ist fett und kursiv.</content>
   :
</text>

1.4.5 Erweiterte styleCodes

Neben den vom CDA-Standard vorgesehenen Möglichkeiten der Formatierung von Textelementen, erlaubt dieser Leitfaden die Nutzung weiterer styleCodes. Das ELGA Referenz-Stylesheet unterstützt die Verwendung dieser erweiterten, ELGA-spezifischen StyleCodes.

Die Darstellung der erweiterten, ELGA-spezifischen StyleCodes erfordert ein speziell angepasstes Stylesheet (z.B. das ELGA Referenz-Stylesheet).

Textstrukturen können durch diese ELGA-spezifisch erweiterten StyleCodes formatiert werden, z.B. um bestimmte Abschnitte wie Überschriften oder Unterüberschriften zu formatieren, oder um die Textfarbe zu setzen.

styleCode	Definition	Nutzungsbeispiel
xELGA_h1	Überschriften gem. HTML < h1>	<paragraph styleCode="xELGA_h1">
xELGA_h2	Überschriften gem. HTML < h2>	<paragraph styleCode="xELGA_h2">
xELGA_h3	Überschriften gem. HTML < h3>	<paragraph styleCode="xELGA_h3">
xELGA_blue	CMYK: 100, 60, 0, 6 RGB: 0, 96, 240 HTML: #0060f0	<content styleCode="xELGA_blue"> Anmerkung: Dient zur farblichen Hervorhebung von Wörtern oder Passagen im Fließtext.
xELGA_red	CMYK: 0, 91, 65, 12 RGB 224, 20, 79 HTML: #e3144f Zusätzlich wird der Text Fett dargestellt, da Rot für farbfehlsichtige Personen schwer erkennbar ist.	<tr styleCode="xELGA_red"> Anmerkung: Dient zur farblichen Kennzeichnung von pathologischen Labormesswerten in Tabellen (wird für die ganze Ergebniszeile in einer Tabelle) verwendet.
xELGA_colw:NN	NN...numerische Angabe des Prozentwertes der Spaltenbreite in Tabellen, maximal 2 Ziffern, nur positive Ganzzahlen. Wird nichts angegeben, wird die Spaltenbreite automatisch berechnet (bei n Spalten -- 1/n der gesamten Tabellenbreite)	< th styleCode="xELGA_colw:20"> Die Spaltenbreite entspricht 20% der gesamten Tabellenbreite Anmerkung: Weicht die Summe der angegebenen Spaltenbreiten von 100% ab, wird die Gesamtsumme als 100% angenommen und die einzelnen Spalten entsprechend angepasst
xELGA_tabVertical	Gilt nur für die Ausgabe als Druckvorstufe (PDF): Die Ausrichtung der Tabelle ist um 90% in eine vertikale Orientierung gedreht Defaultausrichtung ist horizontal	< table styleCode="xELGA_tabVertical"> Die Tabelle ist auf einer neuen Seite vertikal ausgerichtet, Tabellenbreite = Seitenhöhe Default: Horizontale Ausrichtung, Tabellenbreite = Textbreite

1.4.6 Zeilenumbrüche

Das br-Element
kann benutzt werden, um im laufenden Text einen „harten“ Zeilumbruch zu erzwingen. Dies unterscheidet es vom paragraph-Element, da der Zeilenumbruch keinen Inhalt hat. Empfänger sind angehalten, dieses Element als Zeilenumbruch darzustellen.

1.4.6.1 Strukturbeispiel

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

1.4.7 Superscript und Subscript

Ein Textbereich kann mit dem Element sup umspannt werden, um ihn Superscript (hochgestellt) darzustellen. Er kann mit sub umspannt werden, um ihn Subscript (tiefgestellt) darzustellen.

1.4.7.1 Strukturbeispiel

<text>
   :
   Dieses Wort ist <sup>hochgestellt</sup>
   Dieses Wort ist <sub>tiefgestellt</sub>
   :
</text>

1.4.8 Fußnoten

Mit den Elementen footnote und footnoteref sind diese Gestaltungsmöglichkeiten im CDA-Standard beschrieben.

1.4.8.1 Strukturbeispiel

Die Fußnotenreferenzen werden fortlaufend nummeriert und durch einen Tag hochgestellt. Der Text wird unter <tfoot> mit dem <footnote> Tag gekennzeichnet. Die ID gibt eine eindeutige Referenz auf den Text einer Fußnote.

<table>
    <thead>
        ...
    </thead>
    <tfoot>
    	<tr>
            <td>
                <footnote ID="fn1"><sup>1)</sup> Wert kontrolliert</footnote>
            </td>
        </tr>
    </tfoot>
    <tbody>
        ...
        <tr ID="OBS-13-1">
            <td ID="OBS-13-1-Code">aPTT</td>
            <td ID="OBS-13-1-Value">57.0
            <!-- Fußnoten werden durch das XSL entsprechend angezeigt -->
                    <sup>1)</sup>
            </td>
            <td ID="OBS-13-1-Unit">s</td>
            <td ID="OBS-13-1-Reference">26.0-40.0</td>
            <td ID="OBS-13-1-Interpretation">++</td>
            <td ID="OBS-13-1-Delta"/>
            <td ID="OBS-13-1-Extern">E</td>
        </tr>
        ...
    <tbody>
</table>

1.4.9 HTML-Verweise

Über das Element linkHtml lassen sich Verweise dokumentintern und auf externe Webseites (ähnlich wie im HTML-Standard beschrieben) realisieren. Wird in diesem Leitfaden nicht genutzt.

1.4.10 Geschützte Leerzeichen

Grundsätzlich werden zusätzliche Leerzeichen am Anfang und am Ende eines Elementinhaltes bei der Darstellung entfernt, auch mehrere Leerzeichen hintereinander (bspw. zwischen Wörtern) werden wie ein Leerzeichen behandelt.

Zusätzlicher Leerraum (whitespace bzw „no-break space“) kann in CDA erzeugt werden durch & #160; oder & #xA0;

Es erzeugt einen Leerraum von einem Zeichen und entspricht dem in HTML verwendeten, in CDA aber NICHT ERLAUBTEN „ “.

1.5 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 medizinischen Inhalt ist, und dass Level 3 Konstrukte dieselbe (aber maschinenauswertbare) Information tragen.

Generell sind in der CDA Entry Auswahl folgende Klassen aus dem RIM modelliert:

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

Dieses Kapitel behandelt den Zusammenhang von text und entry und gibt eine grundsätzliche Anleitung für den Aufbau von Level 3 Strukturen.

1.5.1 Zusammenhang Text und Entry

Elemente innerhalb des Textabschnittes (<text>) nutzen die ID Attribute, um von den zugehörigen Level 3 Entries referenziert zu werden. Dies stellt eine Verknüpfung zwischen dem codierten Eintrag und dem Text dar. 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 mehreren Buchstaben, Zahlen, Bindestrichen oder Unterstrichen.

Referenzierung Text - Entry.

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ürde das folgende Textfragment durch De-Referenzierung der Referenz „#disdiag1_diagnosis“ gewonnen: „M25.46, Meniskus: Empyema gen. sin.“. 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.

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

Zuordnung von Participants zu einzelnen Sections.

1.5.2 Bezug zwischen Entries

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.

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

entryRelationship Klasse. @typeCode gibt 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) ausgedrückt. Dies ist beispielsweise bei Diagnoseninformationen der Fall, 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.

1.6 Untersektionen – Hierarchischer Aufbau

Sektionen können laut CDA Schema beliebig verschachtelt werden.

Eine Sektion kann eine oder mehrere Untersektionen enthalten, welche jeweils wiederum Untersektionen enthalten können, usw.

Verweis auf speziellen Implementierungsleitfaden:
Ob eine Sektion weitere Untersektionen enthält, ist im entsprechenden speziellen Implementierungsleitfaden in der Definition der Sektionen beschrieben.

1.6.1 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
   <!-- CDA Header -->
   :
   <component>
   <!-- strukturierter CDA Body -->
     <structuredBody>
       <component>
         <section>
            <code …/>
            <title>Name der Sektion</name>
            <text>…</text>
            <!-- Untersektion -->
            <component>
               <section>
                  <code …/>
                  <title>Name der Untersektion</name>
                  <text>…</text>
               </section>
            </component>
          </section>
       </component>
     </structuredBody>
   </component>
</ClinicalDocument>

1.7 Einbetten von Dokumenten/Multimedia-Dateien

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 trägt dabei im @referencedObject Attribut die ID auf den Verweis auf das Multimedia-Objekt. Dieser Verweis wird als entry in der ObservationMedia-Klasse abgelegt. Im value-Element des observationMedia-Elements wird das eigentliche Objekt (Dokument, Bild …) eingebettet. Im caption-Unterelement wird eine Beschreibung des Multimedia-Objektes angegeben. Das Referenzstylesheet wird den Inhalt als Mouseover und als Alternativtext ausgeben.

ObservationMedia Klasse zur Ablage von Multimedia-Objekten.

Hinweis zur erlaubten Größe von Multimedia-Inhalten:
Die Gesamtgröße des CDA-Dokumentes bzw. der XML-Datei SOLL 20 MB nicht überschreiten¹⁰. Die Größe der eingebetteten Dateien soll auf ein sinnvolles und angemessenes Mininum beschränkt werden.

Siehe auch „Größenbeschränkung von eingebetteten Objekten“.

Hinweis zur Verwendung von Multimedia-Inhalten und Barrierefreiheit:
Die Empfänger der Dokumente haben unterschiedliche Ausgabegeräte und unterschiedliche Bedürfnisse. Bilder, sowie Audio- und Videodateien werden möglicherweise nicht dargestellt oder gedruckt werden können. Bitte beachten Sie also im Sinne der Barrierefreiheit folgende Punkte

• Bei Multimedia-Daten MÜSSEN die relevanten Inhalte immer im lesbaren Text beschrieben werden.
• Wo Multimedia-Dateien normalerweise angezeigt werden, MUSS eine sprechende Beschreibung ihres Inhaltes angegeben werden (z.B. Textalternative, Bildunterschrift).
• Die Textalternative für Bilddaten SOLL auch im Unterelement von <renderMultimedia> angegeben werden, dieses Element kann in Screenreadern entsprechend ausgewertet werden und erhöht die Barrierefreiheit.
• Grafiken mit Transparenzen sind NICHT ERLAUBT.

¹⁰ Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt.

1.7.1 Strukturbeispiele

1.7.1.1 Eingebettetes PDF

Das folgende Beispiel beschreibt einen eingebetteten Befund, der in der Sektion „Beigelegte Befunde“ angegeben wurde.

<section>
   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.31"/>
   <code code="BEFBEI"
         displayName="Beigelegte erhobene Befunde"
         codeSystem="1.2.40.0.34.5.40"
         codeSystemName="ELGA_Sections"/>
   <title>Beigelegte erhobene Befunde</title>
   <text>
     <table>
        <thead>
           <tr>
              <th>Name des Dokuments</th>
              <th>Datum</th>
              <th>Dokument</th>
           </tr>
       </thead>
       <tbody>
           <tr>
              <td>Laborbefund</td>
              <td>01.01.2009</td>
              <td><renderMultiMedia referencedObject="MM1">
                  <caption>Eingebetteter Laborbefund</caption>
                  </renderMultimedia>
              </td>
           </tr>
        </tbody>
      </table>
   </text>
   <entry>
     <observationMedia classCode="OBS" moodCode="EVN" ID="MM1">
       <!-- ELGA EingebettetesObjekt-Entry -->
       <templateId root="1.2.40.0.34.11.1.3.1"/>
       <value
           mediaType="application/pdf"
           representation="B64">
           JVBEi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyI
           C9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1aW28dtxFGnLfzK/ap3S0ihveLU
           M5z5OHt+bjgTznIVGh7/o/84Xi0+PwjN+d3i54Vh1nNjezltH6+a50sYJngj
           AuOu2Z5thB9n2gcZ55r2XjoEzBjuVq0Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ90
           e0opgNXrv2p40zBn/YAZU0HLR+cb3lnW Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ
            :      :      :
       </value>
     </observationMedia>
   </entry>
</section>

1.7.1.2 Eingebettetes Bild

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

<section>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.31"/>
    <code
       code="29554-3" codeSystem="2.16.840.1.113883.6.1"
       codeSystemName="LOINC" displayName="Prozeduren"/>
    <title>Durchgeführte Maßnahmen</title>
    <text>Rötung an der Palmarfläche des linken Zeigefingers
       <renderMultiMedia referencedObject="MM1"/>
         <caption>Roter Fleck am linken Zeigefinger</caption>
       </renderMultiMedia>
    </text>
    <entry>
       <observationMedia classCode="OBS" moodCode="EVN" ID="MM1">
       <!-- ELGA EingebettetesObjekt-Entry -->
       <templateId root="1.2.40.0.34.11.1.3.1"/>
         <value
            mediaType="image/jpeg"
            representation="B64">
          JVBEi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyI
          C9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nM1aW28dtxFGnLfzK/ap3S0ihveLU
          AQYydprBSJcJICNvqgu1TrSI4kN0H+bF76M/LQ4S7Jmd3DlY/kg6IO4NBDch
          e0opgNXrv2p40zBn/YAZU0HLR+cb3lnW Tbf8V5wAUhjvQqhNUJyZ4E2c8KZ
            :      :      :
         </value>
       </observationMedia>
     </entry>
</section>

1.7.2 Spezifikation

Siehe „ELGA EingebettetesObjekt-Entry“.

1.7.3 Zugelassene mediaType Attribut-Werte

Der Datentyp von Multimedia-Objekten ist immer ED (encapsulated data). Dabei ist auch der Medientyp (MIME) im entsprechenden @mediaType Attribut zu nennen.

Zulässige Werte gemäß Value-Set „ELGA_Medientyp“

Verweis auf speziellen Implementierungsleitfaden:
Spezielle Implementierungsleitfäden können zusätzliche Medientypen (MIME) erlauben.

Achtung: Grafiken mit Transparenz (z.B: bei GIF oder PNG möglich) können zu schweren Problemen bei der Wiedergabe oder Konvertierung zu PDF/A-1 führen und sind daher NICHT ERLAUBT.