Änderungen

==Allgemeiner Aufbau des CDA Body==

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

====Strukturbeispiel====

<ClinicalDocument xmlns="urn:hl7-org:v3">

:

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.

====Strukturbeispiel====

<ClinicalDocument xmlns="urn:hl7-org:v3">

:

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

<section>

<title>Aufnahmegrund</title>

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

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

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

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

====Spezifikation====

{{:1.2.40.0.34.11.30001/dynamic}}

===Textstrukturierung===

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:

{| class="wikitable" width="100%"

=====Strukturbeispiel=====

Eine Liste hat das folgende Aussehen:

<text>

:

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 [[ILF:Allgemeiner Implementierungsleitfaden#Fu.C3.9Fnoten|Fußnoten]])

Die Vorgaben für Tabellen MÜSSEN korrekt eingehalten werden, damit sie zuverlässig und korrekt durch Stylesheets dargestellt werden können.

=====Strukturbeispiel=====

Eine Tabelle hat das folgende Aussehen:

<text>

:

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

=====Strukturbeispiel=====

<text>

:

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

<text>

:

|- style="background:#FFFFFF"

|- style="background:#FFFFFF"

|- style="background:#FFFFFF"

| xELGA_tabVertical||'''Gilt nur für die Ausgabe als Druckvorstufe (PDF)''': Die Ausrichtung der Tabelle ist um 90% in eine vertikale Orientierung gedreht <br/>Defaultausrichtung ist horizontal ||< table styleCode="xELGA_tabVertical"><br/>Die Tabelle ist auf einer neuen Seite vertikal ausgerichtet, <br/>Tabellenbreite = Seitenhöhe<br/>Default: Horizontale Ausrichtung, Tabellenbreite = Textbreite

|-

|}

====Zeilenumbrüche====

=====Strukturbeispiel=====

<text>

:

====Superscript und Subscript====

=====Strukturbeispiel=====

<text>

:

=====Strukturbeispiel=====

Die Fußnotenreferenzen werden fortlaufend nummeriert und durch einen ''<sup>'' 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>

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

===Strukturen in Level 3===

|-

|}

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

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

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.

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

====Bezug zwischen Entries====

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

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.

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

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

=====Strukturbeispiel=====

<ClinicalDocument xmlns="urn:hl7-org:v3">

:

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.

{{BeginYellowBox}}

{{EndYellowBox}}

Siehe auch „[[ILF:Allgemeiner Implementierungsleitfaden#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Größenbeschränkung von eingebetteten Objekten]]“.

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

* Die Textalternative für Bilddaten SOLL auch im <caption> Unterelement von <renderMultimedia> angegeben werden, dieses Element kann in Screenreadern entsprechend ausgewertet werden und erhöht die Barrierefreiheit.

* Grafiken mit Transparenzen sind NICHT ERLAUBT.

====Strukturbeispiele====

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

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

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

Spezielle Implementierungsleitfäden können zusätzliche Medientypen (MIME) erlauben.

{{BeginYellowBox}}

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.

{{EndYellowBox}}