Body

Aus Hl7wiki
(Teildokument von Arztbrief 2.x)
Wechseln zu: Navigation, Suche
(→‎Allgemeiner Aufbau des Body)
(→‎Levels)
 
(49 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
  
−
{{DocumentPart}}
+
==CDA R2 Body==
 +
===Allgemeiner Aufbau des Body===
 +
Während im CDA Header die Akteure und mehr oder weniger administrative Inhalte wie Informationen über das Dokument selbst, den Patienten, den Autor etc. festgelegt wurden, enthält der CDA Body des hier definierten Arztbriefes die eigentliche klinische Dokumentation und stellt den „menschenlesbaren" medizinischen Teil dar.
  
−
=CDA R2 Body=
+
Der hier definierte Arztbrief besteht im Body entweder aus einem ''nonXMLBody'' oder einem ''structuredBody'' Element, das wiederum ''section'' Elemente aufweist, mit denen die Information strukturiert werden kann. Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man ''nonXMLBody'' verwenden (CDA Level1), das Dokumente entweder referenziert oder eingebettet wiedergeben.
  
−
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.
 
Danach zeichnet sich für den Arztbrief folgende Grobstruktur ab.
  
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
 +
Variante 1 - unstrukturierter Body
 +
 +
<ClinicalDocument>
 +
  <!-- CDA Header -->
 +
      ... siehe Beschreibung CDA R2 Header
 +
  <!-- CDA Body -->
 +
  <component>
 +
    <nonXMLBody>
 +
      <text mediaType="application/pdf" representation="B64">
 +
        sadsfFAETQETEdfgStreTdsfgSrgregWRTERtSFGwERtwtergq45ttGw5TW%TwtR%TG
 +
        vbnbnDJDZwrGTarGFaerewFasFaGaERgGtRzRthsYDFfGeRTertwerfFgERT3$RT34r
 +
        dfE$R%34ReFD34T34TG§$t§4%T3ER§4t5§4TWEWRt§$t5§$t§g§$rt§$tGF$§t§$t$t
 +
        ...
 +
        cwER"§$wer§$65$%gTGH5643FD§$KJDU21%ZuTz$%z3vXCvSDf2EQeGFE§rwFG3$T%$
 +
        e545REG34T%$gtrfgeg=
 +
      </text>
 +
      <languageCode code="de-DE"/>
 +
    </nonXMLBody>
 +
  </component>
 +
</ClinicalDocument>
 +
</syntaxhighlight>
 +
 +
<syntaxhighlight lang="xml">
 +
Variante 2 - strukturierter Body
 +
 
<ClinicalDocument>
 
<ClinicalDocument>
 
   <!-- CDA Header -->
 
   <!-- CDA Header -->
Zeile 22: Zeile 47:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
 +
====nonXMLBody (Variante 1)====
  
−
==Allgemeiner Aufbau des Body==
+
Wie bereits angedeutet gibt es die Möglichkeit, lediglich den Header zur Übermittlung von strukturierten Metadaten zu einem Arztbrief zu nutzen:
−
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''
+
{{HL7img|Cdaab2_nonxmlbody.jpg|300px|40%}}
−
''ED \[0..1\]''
 
  
−
[[file:Cdaab2_body.jpg|Body]]
+
<ref group="Abbildung">CDA nonXMLBody</ref> ''CDA nonXMLBody''
  
−
''Abbildung 18: Section-Klasse mit ihren Attributen. Sections können auch Subsections (als Komponente) enthalten, also ineinander geschachtelt sein.''
+
Bei dieser Variante wird der Inhalt als Ganzes übermittelt. In diesem Fall besteht der Body lediglich aus einer verkürzten XML-Struktur, in der das Dokument eingebettet ist. Dann kann es allerdings nicht weiterverarbeitet und nur zur Anzeige mit einem geeigneten Viewer gebracht werden. In diesem Fall kommt ausschließlich die nonXMLBody-Section zum Einsatz.
  
 +
====structuredBody (Variante 2)====
  
−
In der folgenden Grafik ist wiedergegeben, dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht. Diese können auch ineinander geschachtelt sein, um so – ähnlich wie in einem Buch – Unterabschnitte zu reflektieren. Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, 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.
+
In der folgenden Grafik ist wiedergegeben, dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht. Diese können auch ineinander geschachtelt sein, um so – ähnlich wie in einem Buch – Unterabschnitte zu reflektieren. Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, das sich wiederum untergliedern könnte in „Eigenanamnese", „Familienanamnese", „Sozialanamnese" sowie „bisherige Operationen", „bisherige Impfungen" etc. In der Regel sind die Abschnitte mit Codes versehen (siehe unten). Manche Abschnitte sind mit zusätzlichen Einträgen (Komponenten) versehen, die RIM-Klassen entsprechen und hochstrukturierte Codierungen zulassen.
  
 
Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.
 
Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.
Zeile 43: Zeile 66:
 
* Text in Abschnitten und Unterabschnitten, zusätzlich mit codierten Einträgen, die RIM-Klassen entsprechen (Level 3, 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]]
+
{{HL7img|Cdaab1_body.jpg|600px|80%}}
 +
 
 +
<ref group="Abbildung">Übersicht über den Body-Teil des CDA-Dokuments</ref> ''Übersicht über den Body-Teil des CDA-Dokuments. Die medizinische Dokumentation wird als Text in Abschnitten abgelegt, die vorzugsweise mit Codes identifiziert sind. Innerhalb eines Abschnitts kann es optionale Unterabschnitte geben, die eine weiter gehende Strukturierung ermöglichen. Für Diagnosen werden neben codierten Abschnitten auch hochstrukturierte Komponenten vorgesehen, die RIM-Klassen (z. B. Observation) entsprechen. Hier ist als Beispiel der Diagnose-Code für eine Entlass-Diagnose angedeutet.''
 +
 
 +
Der ''structuredBody'' eines CDA Release 2 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente wiederum aus einer oder mehreren Sektionen und gegebenenfalls aus einem oder mehreren „Entry"-Elementen (siehe Abschnitt „Level: 1 bis 3") besteht.
 +
 
 +
Das bedeutet unter anderem, dass ein CDA-Dokument dahingehend näher bestimmt werden kann, dass es spezifische Abschnitte, Paragrafen und andere Strukturbestandteile aufweisen muss. So kann ein Entlassbrief aus der Urologie beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein OP-Bericht oder ein Pathologie-Befund ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann bzw. muss.
 +
 
 +
{{ConstraintBox|
 +
Für strukturierte CDA-Dokumente (structuredBody) gilt, dass ein Clinical Document mindestens ein „section"-Element enthalten muss.
 +
Jede Sektion muss genau ein „Text"-Element enthalten, das nicht leer sein darf.
 +
}}
 +
 
 +
====Attribute von strukturierten Sections====
 +
=====Section.title: Titel des Abschnitts=====
 +
Das ''section'' Element enthält einen optionalen Titel. Näheres regeln die entsprechenden spezialisierten Templates.
 +
=====Section.text: Text des Abschnitts=====
 +
Das ''section'' Element enthält eine narrative Beschreibung des Inhaltes und ist verpflichtend anzugeben.
 +
{{NoteBox|
 +
Der Text in den Abschnitten kann mit bestimmten Elementen strukturiert werden, die im Abschnitt '''Textstrukturierung''' genauer beschrieben sind.
 +
}}
 +
=====Section.code: Klassifizierung des Abschnitts=====
 +
Das ''section'' Element kann ein ''code'' Element enthalten, das den Inhalt des Abschnitts klassifiziert. Als Beispiel ist 10164-2 der LOINC Code für „History of Present Illness".
 +
Im Arztbrief sind zur primären Klassifikation ausschließlich LOINC Codes zugelassen. Alternative Codes können angegeben werden. Näheres regeln die entsprechenden spezialisierten Templates.
 +
 
 +
=====Section.languageCode: Sprache des Abschnitts=====
 +
Jeder Abschnitt kann in einer anderen Sprache geschrieben sein. Dies wird im section-Element ''languageCode'' angegeben, wenn diese von der für das ganze Dokument (mittels ''languageCode'' im Header) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements ''languageCode'' des Headers. Hiervon wird allerdings typischerweise selten Gebrauch gemacht.
 +
 
 +
====Beispiele für Abschnitte in einem Dokument====
 +
 
 +
Ein Dokument besteht aus einem oder mehreren Abschnitten, die bei CDA auch Sections genannt werden. Nachfolgend ein paar typische Beispiele:
 +
 
 +
*[[cdaab2:Anrede-Section (Template)|Anrede]]
 +
*[[cdaab2:Fragestellung-Section (Template)|Fragestellung]]
 +
*[[cdaab2:Anamnese-Section (Template)|Anamnese]]
 +
*[[cdaab2:Befund-Section (Template)|Befund]]
 +
*Diagnosen
 +
**[[IG:HL7_diagnosen|Diagnoseleitfaden]]
 +
**[[cdaab2:Diagnose-Section (Template)|Diagnose]] (Sektion)
 +
**[[cdaab2:ICD-Diagnose Entry (Template)|ICD-Diagnose]] (Entry)
 +
**[[cdaab2:TNM-Klassifikation-Entry_(Template)|TNM-Klassifikation]] (Entry)
 +
*[[cdaab2:Besondere_Hinweise-Section_(Template)|besondere Hinweise (CAVE)]]
 +
*[[cdaab2:Massnahme-Section (Template)|Therapie/Behandlungsmaßnahme]]
 +
*[[cdaab2:Notiz-Section (Template)|Notiz]]
 +
*[[cdaab2:Epikrise-Section (Template)|Epikrise]]
 +
*[[cdaab2:Medikation-Section (Template)|Medikation]]
 +
*[[cdaab2:Labordaten-Section (Template)|Labordaten]]
 +
*..
 +
*[[cdaab2:Schlusstext-Section (Template)|Schlusstext]]
 +
*[[cdaab2:Anhang-Section (Template)|Anhang]]
 +
 
 +
====Entry====
 +
Die Abschnitte/Sections enthalten den Text, der direkt zur Anzeige verwendet werden soll. Für eine Maschine ist dieser normalerweise nicht direkt auswertbar. Dafür ist ein weiterer Mechanismus vorgesehen, bei dem die dem Text zugrundeliegenden Inhalte strukturiert ausgedrückt und in XML dargestellt werden. Diese Zusatzinformationen werden Entries genannt und innerhalb der Abschnitte optional eingebettet.
  
−
''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.''
+
So kann beispielsweise ein Abschnitt ''Diagnose'' mit einer textuellen Darstellung der Diagnose ("Patient hat Blinddarmentzündung") ein ''Entry Diagnose'' enthalten, in dem die Diagnose als ICD-Code mit allen dazugehörigen Metadaten dargestellt wird.
 +
 
 +
===Levels===
  
−
==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).
 
Die CDA Level repräsentieren die unterschiedliche Feinheit (Granularität) der wiedergegebenen klinischen Informationen und des maschinen-auswertbaren Markups (standardisierte Form der maschinenauswertbaren Auszeichnung von Text).
 +
 +
====Level 1====
 +
 
Mit '''Level 1''' ist ein XML Dokument gekennzeichnet, das vor allem auf „menschliche Interoperabilität" abzielt („human readable"), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann, zum Beispiel durch Stylesheets. Es gibt keine Einschränkungen den Gebrauch oder Zweck des Dokuments oder den Inhalt betreffend. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der reinen Papierwelt bekannt ist.
 
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''
+
{{HL7img|Cdaab1_section_lvl1.jpg|500px|60%}}
−
''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.
+
<ref group="Abbildung">CDA Level 1</ref> ''CDA Level 1''
  
−
[[file:Cdaab1_section_lvl1.gif|500px|Section Level1]]
+
====Level 2====
  
−
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.
+
Im '''Level 2''' wird der Aufbau der Abschnitte genauer festgelegt. Diese Festlegung kann sowohl die textuelle Darstellung mit &lt;text> und &lt;title> Elementen betreffen als auch die Vorgabe, den Abschnitt mit einem bestimmten Code kenntlich zu machen.
  
−
''Section.code Klassifizierung des Abschnitts''
+
Die Identifikation dieser Abschnitte ist dann auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird typischerweise erreicht durch die Assoziation des Abschnitts mit einem Code (oder einem Set von mehreren Codes). Hierfür werden in diesem Leitfaden ausschließlich LOINC Codes zur Dokumentenabschnittsklassifizierung verwendet. Eine andere Möglichkeit der Kenntlichmachung ist die Zuordnung einer Template-Identifikation, von der in dieser Spezifikation auch Gebrauch gemacht wird (siehe unten).
−
''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".
+
{{HL7img|Cdaab1_section_lvl2.jpg|500px|60%}}
−
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]]
+
<ref group="Abbildung">CDA Level 2</ref> ''CDA Level 2''
  
 +
Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinen-auswertbar, d. h. durch Applikationen identifizierbar. Das bedeutet unter anderem, dass ein CDA Abschnitt dahingehend näher bestimmt werden kann, dass es spezifische Textteile (Paragraphen, Listen, Tabllen, etc.) aufweisen muss. So kann für einen Abschnitt mit Labordaten bspw. genau die Tabellenstruktur vorgegeben werden, d.h. welche Spalten in welcher Reihenfolge zu erscheinen haben.
  
−
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. In Arztbriefen - wofür dieser Leitfaden entwickelt wurde - macht man hier relativ wenig Vorgaben, während in Formularen oder Berichten relativ genaue Vorgaben zu erwarten sind.
  
−
Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z. B. ein OP-Bericht.  
+
Die häufigste Präzisierung ist die Vorgabe einer Menge von Codes für das Attribut '''code'''.
  
−
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.
+
====Level 3====
  
−
[[file:Cdaab1_section_lvl3.gif|500px|Section Level3]]
+
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.
  
 +
{{HL7img|Cdaab1_section_lvl3.jpg|500px|60%}}
  
−
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.
+
<ref group="Abbildung">CDA Level 3</ref> ''CDA Level 3''
 +
 
 +
Ingesamt spricht man bei CDA und der hier beschriebenen Architektur der Level von einer „inkrementellen bzw. variablen semantischen Interoperabilität". Das heißt schlicht, dass man sehr „bescheiden" anfangen kann und elektronische Dokumente nutzt, die im Wesentlichen Gegenstücke zum Papier sind: Mensch-Mensch-Interoperabilität. Je mehr eine Anwendung oder eine Anwendungsumgebung ermöglicht, desto mehr XML Markup kann man schrittweise zufügen: zunächst dadurch, bestimmte Abschnitte zu identifizieren oder gar zu fordern (Level 2) oder schließlich auf dem Niveau von Einzelinformationen anzugeben bzw. diese verpflichtend zu machen (Level 3). Dies bedeutet dann Anwendungsinteroperabilität.
  
 
Die folgende Grafik gibt eine Section Komponente mit ihren Bestandteilen wieder.
 
Die folgende Grafik gibt eine Section Komponente mit ihren Bestandteilen wieder.
  
−
[[file:Cdaab1_section_comp.gif|500px|Section Components]]
+
{{HL7img|Cdaab1_section_comp.jpg|600px|80%}}
  
 +
<ref group="Abbildung">CDA Section Komponente mit Bestandteilen</ref> ''CDA Section Komponente mit ihren Bestandteilen''
  
−
''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)''
+
''Abbildung: Eine Abschnittskomponente (section) besteht aus einem &lt;code&gt;, der den Abschnitt typisiert, sowie einer Überschrift im &lt;title&gt;. Im obligatorischen &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.''
  
−
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.
+
XML-technisch gesprochen validieren CDA-Dokumente unabhängig vom Level gegen das generische CDA Schema. Zusätzlich können durch Festlegung bzw. Einschränkung der Abschnitte oder Detailinformationen weitere Validierungen verfügbar gemacht und genutzt werden.
  
 
Mit diesem Konzept ist es möglich,  
 
Mit diesem Konzept ist es möglich,  
Zeile 94: Zeile 175:
 
* Dokumente abzubilden, die irgendetwas zwischen diesen beiden Extremen von grober Strukturierung von narrativem Text bis zu feingranulären Einzelinformationen repräsentieren.
 
* 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.
 
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''
+
[[Kategorie:cdaab2|Body]]
−
''CS CNE \[0..1\]''
 
−
 
 
−
==Abschnitte==
 
−
Dies wird in einzelne Abschnitte - auch Sections genannt - aufgeteilt:
 
−
 
 
−
*[[cdaab2:Anrede-Section (Template)|Anrede]]
 
−
*[[cdaab2:Fragestellung-Section (Template)|Fragestellung]]
 
−
*[[cdaab2:Anamnese-Section (Template)|Anamnese]]
 
−
*[[cdaab2:Befund-Section (Template)|Befund]]
 
−
*Diagnosen
 
−
**[[IG:HL7_diagnosen|Diagnoseleitfaden]]
 
−
**[[cdaab2:Diagnose-Section (Template)|Diagnose]] (Sektion)
 
−
**[[cdaab2:ICD-Diagnose Entry (Template)|ICD-Diagnose]] (Entry)
 
−
**[[cdaab2:TNM-Diagnose-Entry (Template)|TNM-Diagnose]] (nach TNM-Klassifikation) (Entry)
 
−
*[[cdaab2:besondere Hinweise (CAVE) Section (Template)|besondere Hinweise (CAVE)]]
 
−
*[[cdaab2:Massnahme-Section (Template)|Therapie/Behandlungsmaßnahme]]
 
−
*[[cdaab2:Notiz-Section (Template)|Notiz]]
 
−
*[[cdaab2:Epikrise-Section (Template)|Epikrise]]
 
−
*[[cdaab2:Medikation-Section (Template)|Medikation]]
 
−
*[[cdaab2:Labordaten-Section (Template)|Labordaten]]
 
−
*..
 
−
*[[cdaab2:Schlusstext-Section (Template)|Schlusstext]]
 
−
*[[cdaab2:Anhang-Section (Template)|Anhang]]
 

Aktuelle Version vom 19. Juli 2015, 14:51 Uhr

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

CDA R2 Body

Allgemeiner Aufbau des Body

Während im CDA Header die Akteure und mehr oder weniger administrative Inhalte wie Informationen über das Dokument selbst, den Patienten, den Autor etc. festgelegt wurden, enthält der CDA Body des hier definierten Arztbriefes die eigentliche klinische Dokumentation und stellt den „menschenlesbaren" medizinischen Teil dar.

Der hier definierte Arztbrief besteht im Body entweder aus einem nonXMLBody oder einem structuredBody Element, das wiederum section Elemente aufweist, mit denen die Information strukturiert werden kann. Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man nonXMLBody verwenden (CDA Level1), das Dokumente entweder referenziert oder eingebettet wiedergeben.

Danach zeichnet sich für den Arztbrief folgende Grobstruktur ab. 

Variante 1 - unstrukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
  <component>
    <nonXMLBody>
      <text mediaType="application/pdf" representation="B64">
        sadsfFAETQETEdfgStreTdsfgSrgregWRTERtSFGwERtwtergq45ttGw5TW%TwtR%TG
        vbnbnDJDZwrGTarGFaerewFasFaGaERgGtRzRthsYDFfGeRTertwerfFgERT3$RT34r
        dfE$R%34ReFD34T34TG§$t§4%T3ER§4t5§4TWEWRt§$t5§$t§g§$rt§$tGF$§t§$t$t
        ...
        cwER"§$wer§$65$%gTGH5643FD§$KJDU21%ZuTz$%z3vXCvSDf2EQeGFE§rwFG3$T%$
        e545REG34T%$gtrfgeg=
      </text>
      <languageCode code="de-DE"/>
    </nonXMLBody>
  </component>
</ClinicalDocument>

Variante 2 - strukturierter Body

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

nonXMLBody (Variante 1)

Wie bereits angedeutet gibt es die Möglichkeit, lediglich den Header zur Übermittlung von strukturierten Metadaten zu einem Arztbrief zu nutzen:

Cdaab2 nonxmlbody.jpg

Cdaab2 nonxmlbody.jpg

[Abbildung 1] CDA nonXMLBody

Bei dieser Variante wird der Inhalt als Ganzes übermittelt. In diesem Fall besteht der Body lediglich aus einer verkürzten XML-Struktur, in der das Dokument eingebettet ist. Dann kann es allerdings nicht weiterverarbeitet und nur zur Anzeige mit einem geeigneten Viewer gebracht werden. In diesem Fall kommt ausschließlich die nonXMLBody-Section zum Einsatz.

structuredBody (Variante 2)

In der folgenden Grafik ist wiedergegeben, dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht. Diese können auch ineinander geschachtelt sein, um so – ähnlich wie in einem Buch – Unterabschnitte zu reflektieren. Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, das sich wiederum untergliedern könnte in „Eigenanamnese", „Familienanamnese", „Sozialanamnese" sowie „bisherige Operationen", „bisherige Impfungen" etc. In der Regel sind die Abschnitte mit Codes versehen (siehe unten). Manche Abschnitte sind mit zusätzlichen Einträgen (Komponenten) versehen, die RIM-Klassen entsprechen und hochstrukturierte Codierungen zulassen.

Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.

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

Cdaab1 body.jpg

Cdaab1 body.jpg

[Abbildung 2] Übersicht über den Body-Teil des CDA-Dokuments. Die medizinische Dokumentation wird als Text in Abschnitten abgelegt, die vorzugsweise mit Codes identifiziert sind. Innerhalb eines Abschnitts kann es optionale Unterabschnitte geben, die eine weiter gehende Strukturierung ermöglichen. Für Diagnosen werden neben codierten Abschnitten auch hochstrukturierte Komponenten vorgesehen, die RIM-Klassen (z. B. Observation) entsprechen. Hier ist als Beispiel der Diagnose-Code für eine Entlass-Diagnose angedeutet.

Der structuredBody eines CDA Release 2 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente wiederum aus einer oder mehreren Sektionen und gegebenenfalls aus einem oder mehreren „Entry"-Elementen (siehe Abschnitt „Level: 1 bis 3") besteht.

Das bedeutet unter anderem, dass ein CDA-Dokument dahingehend näher bestimmt werden kann, dass es spezifische Abschnitte, Paragrafen und andere Strukturbestandteile aufweisen muss. So kann ein Entlassbrief aus der Urologie beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein OP-Bericht oder ein Pathologie-Befund ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann bzw. muss.

Conformance.svg Für strukturierte CDA-Dokumente (structuredBody) gilt, dass ein Clinical Document mindestens ein „section"-Element enthalten muss. Jede Sektion muss genau ein „Text"-Element enthalten, das nicht leer sein darf.

Attribute von strukturierten Sections

Section.title: Titel des Abschnitts

Das section Element enthält einen optionalen Titel. Näheres regeln die entsprechenden spezialisierten Templates.

Section.text: Text des Abschnitts

Das section Element enthält eine narrative Beschreibung des Inhaltes und ist verpflichtend anzugeben.

Information icon.svg Der Text in den Abschnitten kann mit bestimmten Elementen strukturiert werden, die im Abschnitt Textstrukturierung genauer beschrieben sind.
Section.code: Klassifizierung des Abschnitts

Das section Element kann ein code Element enthalten, das den Inhalt des Abschnitts klassifiziert. Als Beispiel ist 10164-2 der LOINC Code für „History of Present Illness". Im Arztbrief sind zur primären Klassifikation ausschließlich LOINC Codes zugelassen. Alternative Codes können angegeben werden. Näheres regeln die entsprechenden spezialisierten Templates.

Section.languageCode: Sprache des Abschnitts

Jeder Abschnitt kann in einer anderen Sprache geschrieben sein. Dies wird im section-Element languageCode angegeben, wenn diese von der für das ganze Dokument (mittels languageCode im Header) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements languageCode des Headers. Hiervon wird allerdings typischerweise selten Gebrauch gemacht.

Beispiele für Abschnitte in einem Dokument

Ein Dokument besteht aus einem oder mehreren Abschnitten, die bei CDA auch Sections genannt werden. Nachfolgend ein paar typische Beispiele:

Entry

Die Abschnitte/Sections enthalten den Text, der direkt zur Anzeige verwendet werden soll. Für eine Maschine ist dieser normalerweise nicht direkt auswertbar. Dafür ist ein weiterer Mechanismus vorgesehen, bei dem die dem Text zugrundeliegenden Inhalte strukturiert ausgedrückt und in XML dargestellt werden. Diese Zusatzinformationen werden Entries genannt und innerhalb der Abschnitte optional eingebettet.

So kann beispielsweise ein Abschnitt Diagnose mit einer textuellen Darstellung der Diagnose ("Patient hat Blinddarmentzündung") ein Entry Diagnose enthalten, in dem die Diagnose als ICD-Code mit allen dazugehörigen Metadaten dargestellt wird.

Levels

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

Level 1

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

Cdaab1 section lvl1.jpg

Cdaab1 section lvl1.jpg

[Abbildung 3] CDA Level 1

Level 2

Im Level 2 wird der Aufbau der Abschnitte genauer festgelegt. Diese Festlegung kann sowohl die textuelle Darstellung mit <text> und <title> Elementen betreffen als auch die Vorgabe, den Abschnitt mit einem bestimmten Code kenntlich zu machen.

Die Identifikation dieser Abschnitte ist dann auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird typischerweise erreicht durch die Assoziation des Abschnitts mit einem Code (oder einem Set von mehreren Codes). Hierfür werden in diesem Leitfaden ausschließlich LOINC Codes zur Dokumentenabschnittsklassifizierung verwendet. Eine andere Möglichkeit der Kenntlichmachung ist die Zuordnung einer Template-Identifikation, von der in dieser Spezifikation auch Gebrauch gemacht wird (siehe unten).

Cdaab1 section lvl2.jpg

Cdaab1 section lvl2.jpg

[Abbildung 4] CDA Level 2

Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinen-auswertbar, d. h. durch Applikationen identifizierbar. Das bedeutet unter anderem, dass ein CDA Abschnitt dahingehend näher bestimmt werden kann, dass es spezifische Textteile (Paragraphen, Listen, Tabllen, etc.) aufweisen muss. So kann für einen Abschnitt mit Labordaten bspw. genau die Tabellenstruktur vorgegeben werden, d.h. welche Spalten in welcher Reihenfolge zu erscheinen haben.

Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z.B. ein OP-Bericht. In Arztbriefen - wofür dieser Leitfaden entwickelt wurde - macht man hier relativ wenig Vorgaben, während in Formularen oder Berichten relativ genaue Vorgaben zu erwarten sind.

Die häufigste Präzisierung ist die Vorgabe einer Menge von Codes für das Attribut code.

Level 3

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich auf dem Niveau von Einzelinformationen maschinen-auswertbare Komponenten (wie beispielsweise „systolischer Blutdruck"), die RIM-Klassen entsprechen. Eine Anwendung kann damit Daten wie eine einzelne Beobachtung, Prozedur, Medikamentengabe etc. identifizieren und verarbeiten. Selbst die Anwesenheit von bestimmten Einzelinformationen kann durch Vorgaben (Templates-Konzept) verpflichtend gemacht werden.

Cdaab1 section lvl3.jpg

Cdaab1 section lvl3.jpg

[Abbildung 5] CDA Level 3

Ingesamt spricht man bei CDA und der hier beschriebenen Architektur der Level von einer „inkrementellen bzw. variablen semantischen Interoperabilität". Das heißt schlicht, dass man sehr „bescheiden" anfangen kann und elektronische Dokumente nutzt, die im Wesentlichen Gegenstücke zum Papier sind: Mensch-Mensch-Interoperabilität. Je mehr eine Anwendung oder eine Anwendungsumgebung ermöglicht, desto mehr XML Markup kann man schrittweise zufügen: zunächst dadurch, bestimmte Abschnitte zu identifizieren oder gar zu fordern (Level 2) oder schließlich auf dem Niveau von Einzelinformationen anzugeben bzw. diese verpflichtend zu machen (Level 3). Dies bedeutet dann Anwendungsinteroperabilität.

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

Cdaab1 section comp.jpg

Cdaab1 section comp.jpg

[Abbildung 6] CDA Section Komponente mit ihren Bestandteilen

Abbildung: Eine Abschnittskomponente (section) besteht aus einem <code>, der den Abschnitt typisiert, sowie einer Überschrift im <title>. Im obligatorischen <text> Teil sind die lesbaren Informationen repräsentiert. Dies ist verknüpft mit dem Begriff Level 2. Teile des narrativen Texts können darüber hinaus maschinenauswertbar im Level 3 repräsentiert werden, den so genannten CDA Entries <entry>. Zwischen Teilen des narrativen Texts und den Entries können Verbindungen angegeben werden.

XML-technisch gesprochen validieren CDA-Dokumente unabhängig vom Level gegen das generische CDA Schema. Zusätzlich können durch Festlegung bzw. Einschränkung der Abschnitte oder Detailinformationen weitere Validierungen verfügbar gemacht und genutzt werden.

Mit diesem Konzept ist es möglich,

  • narrative Befunde elektronisch strukturiert wiederzugeben, so wie sie heute in der papierbasierten Welt zu finden sind, mit oder ohne zusätzliches Markup. Gleichzeitig wird gewährleistet, dass so viele gemeinsame Informationen wie möglich den Anwendungen zur Verfügung stehen (shared semantics), wie zum Beispiel die Identifikation und andere allgemeine Daten des Patienten.
  • feingranulierte und kodierte Informationen darzustellen, wie Diagnosen, Prozeduren, Medikationen etc., die in (ggf. vorgegebenen) Kodierschemas wie ICD 10 repräsentiert sind, sowie Mess- oder Laborergebnisse darzustellen.
  • Dokumente abzubilden, die irgendetwas zwischen diesen beiden Extremen von grober Strukturierung von narrativem Text bis zu feingranulären Einzelinformationen repräsentieren.

Man kann dies auch als Möglichkeit ansehen, „sanft" und ohne allzu hohe Ansprüche zu beginnen, elektronische Dokumente einzuführen und mit steigenden Anforderungen und technischen Möglichkeiten zu höherer Anwendungsinteroperabilität zu migrieren.
Referenzfehler: Es sind <ref>-Tags für die Gruppe „Abbildung“ vorhanden, jedoch wurde kein dazugehöriges <references group="Abbildung" />-Tag gefunden oder ein schließendes </ref> fehlt.

Abgerufen von „https://wiki.hl7.de/index.php?title=cdaab2:Body&oldid=25102“