Cdapueb:Grundlagen

Aus Hl7wiki
(Teildokument von )
Wechseln zu: Navigation, Suche
(→‎Grundlagen zur Erstellung des CDA-Dokuments)
 
(12 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 56: Zeile 56:
 
Die jeweiligen Angaben können entweder mittels eines Freitextes oder eines Ankreuzkästchens gegeben werden. Eine weitere Möglichkeit hierfür sind Felder wie Name oder Adresse, in die nur die entsprechenden Werte eingetragen werden dürfen. Besonderheiten bestehen bei der aktuellen Medikation, in der die Werte in eine Tabelle eingetragen werden, und beim Hautzustand, in dem die Lokalisation des Dekubitus anhand einer Grafik dargestellt wird. Zudem muss bei einigen elementaren Aktivitäten der Hilfsbedarf, der zur Ausführung nötig ist, eingeschätzt werden. Der Grad des Hilfsbedarfs beginnt bei der Anleitung bis hin zur vollständigen Übernahme der entsprechenden Aktivität. In vielen Feldern ist zusätzlich Platz, um Bemerkungen notieren zu können.
 
Die jeweiligen Angaben können entweder mittels eines Freitextes oder eines Ankreuzkästchens gegeben werden. Eine weitere Möglichkeit hierfür sind Felder wie Name oder Adresse, in die nur die entsprechenden Werte eingetragen werden dürfen. Besonderheiten bestehen bei der aktuellen Medikation, in der die Werte in eine Tabelle eingetragen werden, und beim Hautzustand, in dem die Lokalisation des Dekubitus anhand einer Grafik dargestellt wird. Zudem muss bei einigen elementaren Aktivitäten der Hilfsbedarf, der zur Ausführung nötig ist, eingeschätzt werden. Der Grad des Hilfsbedarfs beginnt bei der Anleitung bis hin zur vollständigen Übernahme der entsprechenden Aktivität. In vielen Feldern ist zusätzlich Platz, um Bemerkungen notieren zu können.
 
== Grundlagen zur Erstellung des CDA-Dokuments ==
 
== Grundlagen zur Erstellung des CDA-Dokuments ==
−
In diesem Leitfaden werden ausschließlich bestehende Header-Level- Templates genutzt <ref>Kategorie:CDA Header Level Template [Internet]. HL7; [aktualisiert 2013 Sep 30; abgerufen 2014 Aug 01]. Verfügbar unter: http://wiki.hl7.de/index.php/Kategorie:CDA_Header_Level_Template</ref>. Dies hat den Grund, dass der Header immer bestimmte Elemente enthalten muss. Diese sind für jedes Dokument gleich und können somit von einem bereits bestehenden Template übernommen werden. Es werden keine Section- und Entry-Level- Templates genutzt, da zum einen nicht für jedes Feld aus dem Pflegeüberleitungsbogen ein Template besteht und zum anderen ohne Templates eine größere Umsetzungsfreiheit herrscht. Durch die Nutzung von Header-Level-Templates können nicht alle Felder aus dem Pflegeüberleitungsbogen in ihrer Ordnung beibehalten werden. Es ist unumgänglich, dass einige Elemente in ihrer Position und in ihrem Umfeld verschoben werden oder zusammen mit anderen ähnlichen Elementen zu einem neuen Element werden. Anschließend wird überprüft, ob alle Einträge aus den Header-Level-Templates im Pflegeüberleitungsbogen enthalten sind oder ob sie lediglich andere Bezeichnungen tragen. Mit diesen Informationen kann der Header ausgefüllt werden. Durch einen Vergleich von Section-Level-Templates <ref>Kategorie:CDA Section Level Template [Internet]. HL7; [aktualisiert 2013 Feb 08; abgerufen 2014 Aug 01]. Verfügbar unter: http://wiki.hl7.de/index.php/Kategorie:CDA_Section_Level_Template</ref> kann die Struktur des Bodys bestimmt werden. Aus dem Aufbau des Headers und Bodys entsteht ein vollständiges CDA-Dokument. Beim Lesen der Tabellen ist wichtig, dass die Gliederungstiefe mithilfe der Levelangabe dargestellt wird. Attribute, die zu einem Tag gehören, sind mit einem @ gekennzeichnet sind und befinden sich in den darauffolgenden Zeilen. Attribute, die mit der Konformität F gekennzeichnet sind, sind in ihrem Wert unveränderbar. Der Wert ist jeweils in der Beschreibung angegeben. In allen Header- und Body-Elementen wird bei der Mindestkardinalität von 0 und der Konformität R davon ausgegangen, dass das Element gänzlich entfällt, sollten keine Daten vorhanden sein.
+
In diesem Leitfaden werden ausschließlich bestehende Header-Level- Templates genutzt <ref name="Kategorie CDA">Kategorie:CDA Header Level Template [Internet]. HL7; [aktualisiert 2013 Sep 30; abgerufen 2014 Aug 01]. Verfügbar unter: http://wiki.hl7.de/index.php/Kategorie:CDA_Header_Level_Template</ref>. Dies hat den Grund, dass der Header immer bestimmte Elemente enthalten muss. Diese sind für jedes Dokument gleich und können somit von einem bereits bestehenden Template übernommen werden. Es werden keine Section- und Entry-Level- Templates genutzt, da zum einen nicht für jedes Feld aus dem Pflegeüberleitungsbogen ein Template besteht und zum anderen ohne Templates eine größere Umsetzungsfreiheit herrscht. Durch die Nutzung von Header-Level-Templates können nicht alle Felder aus dem Pflegeüberleitungsbogen in ihrer Ordnung beibehalten werden. Es ist unumgänglich, dass einige Elemente in ihrer Position und in ihrem Umfeld verschoben werden oder zusammen mit anderen ähnlichen Elementen zu einem neuen Element werden. Anschließend wird überprüft, ob alle Einträge aus den Header-Level-Templates im Pflegeüberleitungsbogen enthalten sind oder ob sie lediglich andere Bezeichnungen tragen. Mit diesen Informationen kann der Header ausgefüllt werden. Durch einen Vergleich von Section-Level-Templates <ref>Kategorie:CDA Section Level Template [Internet]. HL7; [aktualisiert 2013 Feb 08; abgerufen 2014 Aug 01]. Verfügbar unter: http://wiki.hl7.de/index.php/Kategorie:CDA_Section_Level_Template</ref> kann die Struktur des Bodys bestimmt werden. Aus dem Aufbau des Headers und Bodys entsteht ein vollständiges CDA-Dokument. Beim Lesen der Tabellen ist wichtig, dass die Gliederungstiefe mithilfe der Levelangabe dargestellt wird. Attribute, die zu einem Tag gehören, sind mit einem @ gekennzeichnet sind und befinden sich in den darauffolgenden Zeilen. Attribute, die mit der Konformität F gekennzeichnet sind, sind in ihrem Wert unveränderbar. Der Wert ist jeweils in der Beschreibung angegeben. In allen Header- und Body-Elementen wird bei der Mindestkardinalität von 0 und der Konformität R davon ausgegangen, dass das Element gänzlich entfällt, sollten keine Daten vorhanden sein.
 
Im Body befinden sich mehrere sections, die einen oder mehrere entries enthalten. Die sections können jeweils eine oder mehrere Untersections enthalten. Dabei ist jede section von einem ''component''-Tag umschlossen. Die Aufteilung im Body erfolgt auf section- und entry- Basis. Somit gibt es eine Übersichtstabelle zu den sections und eine zu den entries. In einigen Fällen, in denen mehrere entries vorhanden sind, dient die Tabelle als Vorlage. Die für jedes einzelne entry entsprechenden Codes sind unterhalb der Tabelle zu finden. Sollte eine entry- Relationship vorhanden sein, ist sie ebenso separat aufgeführt.
 
Im Body befinden sich mehrere sections, die einen oder mehrere entries enthalten. Die sections können jeweils eine oder mehrere Untersections enthalten. Dabei ist jede section von einem ''component''-Tag umschlossen. Die Aufteilung im Body erfolgt auf section- und entry- Basis. Somit gibt es eine Übersichtstabelle zu den sections und eine zu den entries. In einigen Fällen, in denen mehrere entries vorhanden sind, dient die Tabelle als Vorlage. Die für jedes einzelne entry entsprechenden Codes sind unterhalb der Tabelle zu finden. Sollte eine entry- Relationship vorhanden sein, ist sie ebenso separat aufgeführt.
 
Der Aufbau jeder section erfolgt nach gleichem Schema. Zunächst wird ein Code, das dazugehörige Codesystem und der Name des Codesystems bestimmt. Dieser ist für die Maschinenauswertbarkeit zuständig. Um den section-Code einzubinden wird im Code- Binding Level 2 das Tag ''code'' genutzt. In ihm werden anschließend der Code, das entsprechende Codesystem und der Name des Codesystems vermerkt. Dies geschieht mit folgender Darstellung:
 
Der Aufbau jeder section erfolgt nach gleichem Schema. Zunächst wird ein Code, das dazugehörige Codesystem und der Name des Codesystems bestimmt. Dieser ist für die Maschinenauswertbarkeit zuständig. Um den section-Code einzubinden wird im Code- Binding Level 2 das Tag ''code'' genutzt. In ihm werden anschließend der Code, das entsprechende Codesystem und der Name des Codesystems vermerkt. Dies geschieht mit folgender Darstellung:
Zeile 62: Zeile 62:
 
<code code="Code" codeSystem="System" codeSystemName="Name"/>
 
<code code="Code" codeSystem="System" codeSystemName="Name"/>
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
Die hier verwendeten Codesysteme sind:<br />
 +
• LOINC <ref>LOINC [Internet]. Regenstrief Institute Inc.; Copyright 2014. Search LOINC version 0.9; [abgerufen 2014 July 27]. Verfügbar unter: http://search.loinc.org/</ref><br />
 +
• SNOMED CT <ref>VTSL Terminology Browser [Internet]. VTSL; Copyright 2012. Release July 2014; [abgerufen 2014 July 27]. Verfügbar unter: http://vtsl.vetmed.vt.edu/</ref><br />
 +
• ICD-10-GM <ref>ICD-10-GM Version 2014 [Internet]. DIMDI; Copyright 2014.Version 2014; [aktualisiert 2013 Sep 20; abgerufen 2014 July 27]. Verfügbar unter: http://www.dimdi.de/static/de/klassi/icd-10-gm/kodesuche/onlinefassungen/ htmlgm2014/index.htm</ref><br />
 +
• MeSH <ref>MeSH Browser [Internet]. NLM; Version 2014; [aktualisiert 2014 Jun 10; abgerufen 2014 July 27]. Verfügbar unter: http://www.nlm.nih.gov/mesh/2014/mesh_browser/index.html</ref><br />
 +
• ICF <ref>ICF Version 2005 [Internet]. DIMDI; Copyright 2014. Version 2005; [aktualisiert 2012 Jun 19; abgerufen July 27]. Verfügbar unter: http://www.dimdi.de/dynamic/de/klassi/icf/kodesuche/onlinefassungen/ icfhtml2005/index.htm#</ref><br />
 +
• ATC <ref>Anatomisch-therapeutisch-chemische Klassifikation mit Tagesdosen [Internet]. DIMDI; Copyright 2014. [aktualisiert 2014; abgerufen July 27]. Verfügbar unter: http://www.dimdi.de/dynamic/de/klassi/downloadcenter/atcddd/version2014/atc-ddd- amtlich-2014.pdf</ref><br />
 +
Im Anschluss daran wird jeweils ein Titel für die section vergeben, der in der Beschreibung zu finden ist und nach Möglichkeit nicht verändert werden sollte. Der nächste Teil der section ist eine Angabe zur Strukturierung des Level 1-Textes. Sollte keine Angabe vorhanden sein, ist der Text formlos einzufügen. Je nach Bedarf kann jedoch auch eine Strukturierung festgelegt werden. Besondere Darstellungshinweise befinden sich jeweils unter den Tabellen. Ferner sollte an jedes Listen- oder Tabellenelement nach Möglichkeit eine lokale ID vergeben werden, auf die im entry referenziert werden kann. Wenn jedoch nur ein Teil eines Abschnittes, sei es in einer Tabelle, Liste oder in einem formlosen Text, kodiert wird, ist das Tag ''content'' mit einer entsprechenden ID zu verwenden. Sofern eine ID vergeben wurde, wird im entry-Tag ''originalText'' zusammen mit dem gewählten Code auf das Element mit der ID referenziert, um den Zusammenhang herstellen zu können. Die Referenzierung im entry erfolgt schließlich mit einer URI, die aus einem # und nachfolgend der ID besteht <ref name="Arztbrief">VHitG. Arztbrief Auf Basis der HL7 Clinical Document Architecture Release 2 Für
 +
das deutsche Gesundheitswesen [Internet]. 2006 Sep 27 [aktualisiert 2012 Jun 18; abgerufen 2014 May 31]. Verfügbar unter: http://wiki.hl7.de/index.php/IG:Arztbrief_2006</ref>. Die Wahl der ID sollte so getroffen werden, dass sie eindeutig der betreffenden section zuzuordnen ist. Mehrere IDs in einer section sind durchzunummerieren.
 +
Das entry-Element besitzt immer das Attribut ''typeCode''. Sofern der Text, auf das im entry referenziert wird, vollständig kodiert werden kann, ist im ''typeCode'' „DRIV“ (derived from) zu wählen. Wenn der Code des entrys lediglich Teile des Listen-, Tabellen- oder Freitextelements kodiert, ist „COMP“ (component) zu wählen <ref name="Arztbrief" />. Anschließend ist ein entry- Typ aus dem RIM zu bestimmen. Dieser legt fest, um welche Art von entry es sich handelt. Die in diesem Dokument verwendeten RIM-Klassen sind im Folgenden aufgeführt <ref name="Arztbrief" /><ref>R-MIM-Refined Message Information Models [Internet]. Corepoint Health; [abgerufen 2014 Aug 29]. Verfügbar unter: http://www.corepointhealth.com/resource- center/hl7-resources/r-mim-refined-message-information-model</ref>:
 +
<br />
 +
{| class="wikitable"
 +
! '''RIM-Klasse'''
 +
! '''Beschreibung'''
 +
! '''classCode'''
 +
! '''moodCode'''
 +
|-
 +
| observation
 +
| Beobachtung (z.B. Diagnosebeschreibung)
 +
| OBS
 +
| rowspan="5" style="text-align: center;" | EVN
 +
|-
 +
| encounter
 +
| Patientenkontakt
 +
| ENC
 +
|-
 +
| substanceAdministration
 +
| Angaben zu Medikamenten
 +
| SBADM
 +
|-
 +
| supply
 +
| Verfügbarmachung von Material, Medikamenten oder Hilfsmitteln
 +
| SPLY
 +
|-
 +
| procedure
 +
| Prozedur
 +
| PROC
 +
|}
 +
<br />
 +
Danach folgt je nach Bedarf ein Code für das entry und ein ''value''-Tag, in dem das referenzierte Element kodiert wird. Hierbei handelt es sich um Code-Binding Level 3. Der Code für das entry wird wie beim Code-Binding Level 2 dargestellt. Es gelten zudem die gleichen Codesysteme. Der entry-Code ist jedoch nur dann vorhanden, wenn der Zweck des entrys nicht direkt aus dem section-Code hervorgeht. Der eigentliche Wert wird als Code im ''value''-Tag dargestellt:
 +
<syntaxhighlight lang="xml">
 +
<value xsi:type="CD" code="Code" codeSystem="System" codeSystemName="Name"/>
 +
</syntaxhighlight>
 +
In das ''code''- und das ''value''-Tag ist bei Bedarf auch ''displayName' eizutragen. xsi:type="CD" bezeichnet den Datentyp. Diese Darstellung wird jedoch nur dann verwendet, wenn der Wert als Code darstellbar ist. Sollte dies nicht der Fall sein, kann ein anderer Datentyp eingesetzt werden und der Wert dementsprechend dargestellt werden. Abgeschlossen wird das entry mit dem Tag ''statusCode''. Dieser besitzt immer den Wert „completed“, wenn z.B. eine Beobachtung oder eine Prozedur abgeschlossen ist. Sollte dies nicht der Fall sein, so ist der Wert „active“ zu wählen <ref name="Boone">Boone, Keith W. The CDA Book. London: Springer-Verlag; 2011</ref>.
 +
Um einen Bezug zwischen zwei entries herzustellen, wird das zweite entry eine entry- Relationship. Somit steht es im Zusammenhang mit dem ersten entry <ref name="Arztbrief" />.
 +
<br />
 +
Im folgenden werden die im Header und Body verwendeten Datentypen dargestellt und erläutert <ref name="Boone"/>:
 +
{| class="wikitable"
 +
! '''Datentyp'''
 +
! '''Bedeutung'''
 +
! '''Beschreibung'''
 +
|-
 +
| AD
 +
| Address
 +
| Adressdaten; beinhaltet u.a Angaben zur Straße, Hausnummer, PLZ und Stadt
 +
|-
 +
| CD
 +
| Coded with Equivalents
 +
| kodiertes Konzept
 +
|-
 +
| CNE
 +
| Coded no Exceptions
 +
| der angegebene Wert muss genutzt werden
 +
|-
 +
| CS
 +
| Coded Simple
 +
| es ist ein festgelegter Wert für codeSystem vorhanden; wird nur bei <realmCode>, <languageCode>, <statusCode> und <signatureCode> verwendet
 +
|-
 +
| CWE
 +
| Coded with Exceptions
 +
| der angegebene Wert kann genutzt werden
 +
|-
 +
| ED
 +
| Encapsulated Data
 +
| Übertragung von Daten, die nicht von HL7 vorgesehen sind; Nutzung zur Referenzierung
 +
|-
 +
| II
 +
| Instance Identifier
 +
| Identifikation
 +
|-
 +
| IVL
 +
| Interval
 +
| Intervall (meist einer Zeiteinheit)
 +
|-
 +
| INT
 +
| Integer
 +
| ganzzahlige Werte
 +
|-
 +
| OID
 +
| Object Identifier
 +
| Identifizierung von Codesystemen oder Templates
 +
|-
 +
| ON
 +
| Organisation Name
 +
| Name einer Organisation
 +
|-
 +
| PN
 +
| Person Name
 +
| Name einer Person; kann u.a. Angaben zum Vornamen, Nachnamen und Titel enthalten
 +
|-
 +
| PQ
 +
| Physical Quantity
 +
| physikalische Größe (z.B. Meter, Liter)
 +
|-
 +
| ST
 +
| String
 +
| formloser Text
 +
|-
 +
| TEL
 +
| Telecommunication Address
 +
| Kontaktdaten (z.B. Telefon, E-Mail, Fax)
 +
|-
 +
| TS
 +
| Time Stamp
 +
| Zeitpunkt (Darstellung: YYYY(Jahr)MM(Monat)DD(Tag) hh(Stunde)mm (Minute)ss(Sekunde)
 +
|-
 +
| URI
 +
| Uniform Resource Identifier
 +
| Referenz
 +
|}
 +
Zum Erreichen von Standardkonformität werden eigene Vorgaben gemacht, da für das Dokument im XDS-Container keine Eigenschaften definiert sind. Dabei sind die Eigenschaften des Containers eine Orientierung <ref>Kassner, Andreas. IHE Integrationsprofil XDS.b. [Internet]. [abgerufen 2014 July 30]. Verfügbar unter: http://devel.ztg-nrw.de/ZTG/content/e35/e6520/ e8126/ lecture_downloads8132/ object8136/FolienKassner_ger.pdf</ref>:
 +
{| class="wikitable"
 +
! style="font-weight: bold;" | Wer
 +
! style="font-weight: bold;" | Was
 +
! style="font-weight: bold;" | Wo
 +
! style="font-weight: bold;" | Wann
 +
|-
 +
| • Patient (Identifier, Name, Address, Gender, Date of birth)<br />• Author (Institution, Person, Role, Speciality)<br />• Legal Authentificator
 +
| • Service Event<br />• Confidentiality<br />• Document (Class, Format, Type, Language, Title, URI)
 +
| • Healthcare Facility<br />• Practice Setting
 +
| • Service Start<br />• Service End<br />• Creation
 +
|}

Aktuelle Version vom 26. Januar 2015, 12:38 Uhr

Dieses Material ist Teil des Leitfadens [[Category:|Cdapueb:Grundlagen]].
  • 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: [[:Category:|hier]], Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Grundlagen

Seite 1 des Pflegeüberleitungsbogen
Seite 2 des Pflegeüberleitungsbogen

Auf Basis des Pflegeüberleitungsbogens [Bilder rechts] soll das CDA-Dokument erstellt werden.Der Bogen besteht aus 24 Feldern und einem Unterschriftenfeld, welche im Folgenden kurz erläutert werden:

Der Pflegeüberleitungsbogen

1. Persönliche Daten
Hier werden persönliche Angaben, wie u.a. Name und Adresse des Patienten, gemacht. Zusätzlich werden die Krankenkasse, die Pflegestufe und eventuell vorhandene Dokumente des Patienten angegeben.
2. Vertrauensperson
Die Vertrauensperson sowie ein Angehöriger mit Namen und Kontaktdaten sind anzugeben.
3. Gesetzlicher Betreuer/Bevollmächtigter
Es ist ein gesetzlicher Betreuer und ein Bevollmächtigter jeweils mit Namen und Kontaktdaten anzugeben. Zudem ist anzukreuzen, ob eine Generalvollmacht und eine Patientenverfügung vorliegen. Falls ein Sozialdienst eingeschaltet ist, ist sein Name und die Telefonnummer zu vermerken ebenso wie eventuell vorhandene Wertgegenstände.
4. Verlegung von
Hier ist einzutragen, von wo der Patient verlegt wird und wer die Kontaktperson ist.
5. Verlegung nach
Hier ist anzugeben, wohin der Patient verlegt wird. Auch hier ist eine Kontaktperson einzutragen. Falls der Patient nach Hause verlegt wird, kann das entsprechende Feld angekreuzt werden.
6. Behandelnder Arzt (Hausarzt/Facharzt)
Der behandelnde Arzt ist mit Namen und Kontaktdaten zu vermerken.
7. Pflegerelevante Vorerkrankungen
In diesem Feld kann angegeben werden, welche relevanten Vorerkrankungen der Patient hat. Ebenso sind Infektionen und der Ort des letzten Krankenhausaufenthalts einzutragen.
8. Allergien/Unverträglichkeiten
Eventuell vorhandene Allergien oder Unverträglichkeiten sind hier aufzuführen. Dabei ist zusätzlich zu vermerken, ob der Patient in Besitz eines Allergiepasses ist.
9. Behandlungspflegehinweise
In diesem Feld können frei textlich Hinweise zur Pflege gegeben werden. Zum Beispiel sind dies Angaben zur Wundversorgung.
10. Aktuelle Medikation
Hier kann vermerkt werden, welches Medikament der Patient momentan zu welcher Uhrzeit bekommt. Zudem kann eine Bedarfsmedikation festgelegt werden. Die letzte Medikation und das letzte BTM-Pflaster sind mit Angaben zur Zeit einzutragen. Wenn sich weitere Angaben in der Anlage oder dem Entlassungsschein befinden, kann das entsprechende Feld angekreuzt werden.
11. Vorhandene/verordnete Hilfsmittel
In diesem Feld können frei textlich Angaben zu vorhandenen oder verordneten Hilfsmitteln gegeben werden.
12. Hautzustand
Es wird notiert, wie die Hautbeschaffenheit des Patienten ist. Zudem kann ein Dekubitus mit Angaben zum Grad und der Lokalisation, die anhand einer Grafik zu bestimmen ist, notiert werden. Gleiches gilt für einen Ulkus mit Angaben zur Größe und Lokalisation und für eine Pilzinfektion mit Angaben zur Lokalisation. Sofern sich weitere Hinweise in der Anlage befinden, ist dies entsprechend anzukreuzen.
13. Besondere Pflegeprobleme
Hier werden neun verschiedene Pflegeprobleme aufgelistet. Das entsprechende Element ist bei Übereinstimmung auszuwählen und anzukreuzen.
14. Mobilität
Der Hilfsbedarf, der beim Gehen, Stehen, Sitzen, Bewegen im Bett, Hinsetzen und Hinlegen nötig ist, ist einzuschätzen. Dafür ist der entsprechende Hilfsbedarfswert anzukreuzen. Für jede Aktivität kann zudem ein Hilfsmittel vermerkt werden. Bemerkungen, wie z.B. zum Bewegungsplan, können darunter notiert werden.
15. Ruhen und Schlafen
In diesem Feld werden drei verschiedene Ruhe- und Schlafprobleme aufgelistet, wovon die passenden angekreuzt werden können. Anschließend können Bemerkungen, wie z.B. ob das Bett an der Wand stehen oder freistehend sein muss.
16. Atmung
Auch hier kann das passende Atemproblem oder Atemgerät aus einer Liste ausgewählt und angekreuzt werden. Sollte ein Tracheostoma vorhanden sein, kann zusätzlich bestimmt werden, wann die Kanüle zuletzt gewechselt wurde. Bemerkungen z.B. zum Rauchen sind anschließend zu verfassen.
17. Kommunikation
Hier wird ausgewählt, welche Einschränkungen der Patient bei der Kommunikation hat (z.B. beim Sprechen oder Lesen). Zudem kann notiert werden, ob er eine Brille oder ein Hörgerät trägt. Eventuelle Bemerkungen können abschließend gemacht werden.
18. Essen und Trinken
Der Hilfsbedarf beim Essen und Trinken wird eingeschätzt. Zudem ist aus mehreren Ess- und Trinkproblemen zu wählen. Weiter Angaben sind zur empfohlenen Trinkmenge, zum Sondentyp, zur Sondennahrung, zum Tee und zur Verabreichungsart zu machen. Weitere Informationen zum Essen auf Rädern und zusätzliche Bemerkungen, wie z.B. zu einer Diät, können anschließend gegeben werden.
19. Körperpflege
Der Hilfsbedarf, der beim Baden/Duschen und weiteren Aktivitäten in Hinsicht auf die Körperpflege nötig ist, kann hier eingeschätzt werden. Dazu können jeweils Bemerkungen gemacht werden.
20. Für Sicherheit sorgen/psychische Situation
Hier können Angaben gemacht werden, wie die Bewusstseinslage oder die Tagesstruktur des Patienten aussieht. Weitere Angaben sind zu psychischen Veränderungen, Motivation und Antrieb und zur Orientierung zu geben. Auch hier können eventuelle Bemerkungen notiert werden.
21. Sich beschäftigen
Die Auswahl besteht zwischen Lesen, Radio und TV. Das entsprechende Feld kann angekreuzt werden und es können zusätzlich besondere Interessen beschrieben werden.
22. Sich als Mann/Frau fühlen
In diesem Feld existiert lediglich ein Freitextfeld, in dem Bemerkungen z.B. zum Schamgefühl gemacht werden können.
23. Ausscheiden
Der Hilfsbedarf, der zum Richten der Kleidung und zur hygienischen Nachsorge nötig ist, kann in diesem Feld eingeschätzt werden. Weiterhin können Angaben u.a. zum Stuhlgang und zur Urininkontinenz gemacht werden. Auch hier ist Platz für Bemerkungen.
24. Anlagen
Schließlich ist anzukreuzen, welche Dokumente sich in den Anlagen befinden. Zusätzlich kann notiert werden, wann die telefonische Nachfrage erfolgt und welche Bemerkungen zusätzlich zu machen sind.


Die jeweiligen Angaben können entweder mittels eines Freitextes oder eines Ankreuzkästchens gegeben werden. Eine weitere Möglichkeit hierfür sind Felder wie Name oder Adresse, in die nur die entsprechenden Werte eingetragen werden dürfen. Besonderheiten bestehen bei der aktuellen Medikation, in der die Werte in eine Tabelle eingetragen werden, und beim Hautzustand, in dem die Lokalisation des Dekubitus anhand einer Grafik dargestellt wird. Zudem muss bei einigen elementaren Aktivitäten der Hilfsbedarf, der zur Ausführung nötig ist, eingeschätzt werden. Der Grad des Hilfsbedarfs beginnt bei der Anleitung bis hin zur vollständigen Übernahme der entsprechenden Aktivität. In vielen Feldern ist zusätzlich Platz, um Bemerkungen notieren zu können.

Grundlagen zur Erstellung des CDA-Dokuments

In diesem Leitfaden werden ausschließlich bestehende Header-Level- Templates genutzt [1]. Dies hat den Grund, dass der Header immer bestimmte Elemente enthalten muss. Diese sind für jedes Dokument gleich und können somit von einem bereits bestehenden Template übernommen werden. Es werden keine Section- und Entry-Level- Templates genutzt, da zum einen nicht für jedes Feld aus dem Pflegeüberleitungsbogen ein Template besteht und zum anderen ohne Templates eine größere Umsetzungsfreiheit herrscht. Durch die Nutzung von Header-Level-Templates können nicht alle Felder aus dem Pflegeüberleitungsbogen in ihrer Ordnung beibehalten werden. Es ist unumgänglich, dass einige Elemente in ihrer Position und in ihrem Umfeld verschoben werden oder zusammen mit anderen ähnlichen Elementen zu einem neuen Element werden. Anschließend wird überprüft, ob alle Einträge aus den Header-Level-Templates im Pflegeüberleitungsbogen enthalten sind oder ob sie lediglich andere Bezeichnungen tragen. Mit diesen Informationen kann der Header ausgefüllt werden. Durch einen Vergleich von Section-Level-Templates [2] kann die Struktur des Bodys bestimmt werden. Aus dem Aufbau des Headers und Bodys entsteht ein vollständiges CDA-Dokument. Beim Lesen der Tabellen ist wichtig, dass die Gliederungstiefe mithilfe der Levelangabe dargestellt wird. Attribute, die zu einem Tag gehören, sind mit einem @ gekennzeichnet sind und befinden sich in den darauffolgenden Zeilen. Attribute, die mit der Konformität F gekennzeichnet sind, sind in ihrem Wert unveränderbar. Der Wert ist jeweils in der Beschreibung angegeben. In allen Header- und Body-Elementen wird bei der Mindestkardinalität von 0 und der Konformität R davon ausgegangen, dass das Element gänzlich entfällt, sollten keine Daten vorhanden sein. Im Body befinden sich mehrere sections, die einen oder mehrere entries enthalten. Die sections können jeweils eine oder mehrere Untersections enthalten. Dabei ist jede section von einem component-Tag umschlossen. Die Aufteilung im Body erfolgt auf section- und entry- Basis. Somit gibt es eine Übersichtstabelle zu den sections und eine zu den entries. In einigen Fällen, in denen mehrere entries vorhanden sind, dient die Tabelle als Vorlage. Die für jedes einzelne entry entsprechenden Codes sind unterhalb der Tabelle zu finden. Sollte eine entry- Relationship vorhanden sein, ist sie ebenso separat aufgeführt. Der Aufbau jeder section erfolgt nach gleichem Schema. Zunächst wird ein Code, das dazugehörige Codesystem und der Name des Codesystems bestimmt. Dieser ist für die Maschinenauswertbarkeit zuständig. Um den section-Code einzubinden wird im Code- Binding Level 2 das Tag code genutzt. In ihm werden anschließend der Code, das entsprechende Codesystem und der Name des Codesystems vermerkt. Dies geschieht mit folgender Darstellung: 

<code code="Code" codeSystem="System" codeSystemName="Name"/>

Die hier verwendeten Codesysteme sind:
• LOINC [3]
• SNOMED CT [4]
• ICD-10-GM [5]
• MeSH [6]
• ICF [7]
• ATC [8]
Im Anschluss daran wird jeweils ein Titel für die section vergeben, der in der Beschreibung zu finden ist und nach Möglichkeit nicht verändert werden sollte. Der nächste Teil der section ist eine Angabe zur Strukturierung des Level 1-Textes. Sollte keine Angabe vorhanden sein, ist der Text formlos einzufügen. Je nach Bedarf kann jedoch auch eine Strukturierung festgelegt werden. Besondere Darstellungshinweise befinden sich jeweils unter den Tabellen. Ferner sollte an jedes Listen- oder Tabellenelement nach Möglichkeit eine lokale ID vergeben werden, auf die im entry referenziert werden kann. Wenn jedoch nur ein Teil eines Abschnittes, sei es in einer Tabelle, Liste oder in einem formlosen Text, kodiert wird, ist das Tag content mit einer entsprechenden ID zu verwenden. Sofern eine ID vergeben wurde, wird im entry-Tag originalText zusammen mit dem gewählten Code auf das Element mit der ID referenziert, um den Zusammenhang herstellen zu können. Die Referenzierung im entry erfolgt schließlich mit einer URI, die aus einem # und nachfolgend der ID besteht [9]. Die Wahl der ID sollte so getroffen werden, dass sie eindeutig der betreffenden section zuzuordnen ist. Mehrere IDs in einer section sind durchzunummerieren. Das entry-Element besitzt immer das Attribut typeCode. Sofern der Text, auf das im entry referenziert wird, vollständig kodiert werden kann, ist im typeCode „DRIV“ (derived from) zu wählen. Wenn der Code des entrys lediglich Teile des Listen-, Tabellen- oder Freitextelements kodiert, ist „COMP“ (component) zu wählen [9]. Anschließend ist ein entry- Typ aus dem RIM zu bestimmen. Dieser legt fest, um welche Art von entry es sich handelt. Die in diesem Dokument verwendeten RIM-Klassen sind im Folgenden aufgeführt [9][10]:

RIM-Klasse Beschreibung classCode moodCode
observation Beobachtung (z.B. Diagnosebeschreibung) OBS EVN
encounter Patientenkontakt ENC
substanceAdministration Angaben zu Medikamenten SBADM
supply Verfügbarmachung von Material, Medikamenten oder Hilfsmitteln SPLY
procedure Prozedur PROC


Danach folgt je nach Bedarf ein Code für das entry und ein value-Tag, in dem das referenzierte Element kodiert wird. Hierbei handelt es sich um Code-Binding Level 3. Der Code für das entry wird wie beim Code-Binding Level 2 dargestellt. Es gelten zudem die gleichen Codesysteme. Der entry-Code ist jedoch nur dann vorhanden, wenn der Zweck des entrys nicht direkt aus dem section-Code hervorgeht. Der eigentliche Wert wird als Code im value-Tag dargestellt: 

<value xsi:type="CD" code="Code" codeSystem="System" codeSystemName="Name"/>

In das code- und das value-Tag ist bei Bedarf auch displayName' eizutragen. xsi:type="CD" bezeichnet den Datentyp. Diese Darstellung wird jedoch nur dann verwendet, wenn der Wert als Code darstellbar ist. Sollte dies nicht der Fall sein, kann ein anderer Datentyp eingesetzt werden und der Wert dementsprechend dargestellt werden. Abgeschlossen wird das entry mit dem Tag statusCode. Dieser besitzt immer den Wert „completed“, wenn z.B. eine Beobachtung oder eine Prozedur abgeschlossen ist. Sollte dies nicht der Fall sein, so ist der Wert „active“ zu wählen [11]. Um einen Bezug zwischen zwei entries herzustellen, wird das zweite entry eine entry- Relationship. Somit steht es im Zusammenhang mit dem ersten entry [9].
Im folgenden werden die im Header und Body verwendeten Datentypen dargestellt und erläutert [11]:

Datentyp Bedeutung Beschreibung
AD Address Adressdaten; beinhaltet u.a Angaben zur Straße, Hausnummer, PLZ und Stadt
CD Coded with Equivalents kodiertes Konzept
CNE Coded no Exceptions der angegebene Wert muss genutzt werden
CS Coded Simple es ist ein festgelegter Wert für codeSystem vorhanden; wird nur bei <realmCode>, <languageCode>, <statusCode> und <signatureCode> verwendet
CWE Coded with Exceptions der angegebene Wert kann genutzt werden
ED Encapsulated Data Übertragung von Daten, die nicht von HL7 vorgesehen sind; Nutzung zur Referenzierung
II Instance Identifier Identifikation
IVL Interval Intervall (meist einer Zeiteinheit)
INT Integer ganzzahlige Werte
OID Object Identifier Identifizierung von Codesystemen oder Templates
ON Organisation Name Name einer Organisation
PN Person Name Name einer Person; kann u.a. Angaben zum Vornamen, Nachnamen und Titel enthalten
PQ Physical Quantity physikalische Größe (z.B. Meter, Liter)
ST String formloser Text
TEL Telecommunication Address Kontaktdaten (z.B. Telefon, E-Mail, Fax)
TS Time Stamp Zeitpunkt (Darstellung: YYYY(Jahr)MM(Monat)DD(Tag) hh(Stunde)mm (Minute)ss(Sekunde)
URI Uniform Resource Identifier Referenz

Zum Erreichen von Standardkonformität werden eigene Vorgaben gemacht, da für das Dokument im XDS-Container keine Eigenschaften definiert sind. Dabei sind die Eigenschaften des Containers eine Orientierung [12]:

Wer Was Wo Wann
• Patient (Identifier, Name, Address, Gender, Date of birth)
• Author (Institution, Person, Role, Speciality)
• Legal Authentificator 		• Service Event
• Confidentiality
• Document (Class, Format, Type, Language, Title, URI) 		• Healthcare Facility
• Practice Setting 		• Service Start
• Service End
• Creation
  1. ↑ Kategorie:CDA Header Level Template [Internet]. HL7; [aktualisiert 2013 Sep 30; abgerufen 2014 Aug 01]. Verfügbar unter: http://wiki.hl7.de/index.php/Kategorie:CDA_Header_Level_Template
  2. ↑ Kategorie:CDA Section Level Template [Internet]. HL7; [aktualisiert 2013 Feb 08; abgerufen 2014 Aug 01]. Verfügbar unter: http://wiki.hl7.de/index.php/Kategorie:CDA_Section_Level_Template
  3. ↑ LOINC [Internet]. Regenstrief Institute Inc.; Copyright 2014. Search LOINC version 0.9; [abgerufen 2014 July 27]. Verfügbar unter: http://search.loinc.org/
  4. ↑ VTSL Terminology Browser [Internet]. VTSL; Copyright 2012. Release July 2014; [abgerufen 2014 July 27]. Verfügbar unter: http://vtsl.vetmed.vt.edu/
  5. ↑ ICD-10-GM Version 2014 [Internet]. DIMDI; Copyright 2014.Version 2014; [aktualisiert 2013 Sep 20; abgerufen 2014 July 27]. Verfügbar unter: http://www.dimdi.de/static/de/klassi/icd-10-gm/kodesuche/onlinefassungen/ htmlgm2014/index.htm
  6. ↑ MeSH Browser [Internet]. NLM; Version 2014; [aktualisiert 2014 Jun 10; abgerufen 2014 July 27]. Verfügbar unter: http://www.nlm.nih.gov/mesh/2014/mesh_browser/index.html
  7. ↑ ICF Version 2005 [Internet]. DIMDI; Copyright 2014. Version 2005; [aktualisiert 2012 Jun 19; abgerufen July 27]. Verfügbar unter: http://www.dimdi.de/dynamic/de/klassi/icf/kodesuche/onlinefassungen/ icfhtml2005/index.htm#
  8. ↑ Anatomisch-therapeutisch-chemische Klassifikation mit Tagesdosen [Internet]. DIMDI; Copyright 2014. [aktualisiert 2014; abgerufen July 27]. Verfügbar unter: http://www.dimdi.de/dynamic/de/klassi/downloadcenter/atcddd/version2014/atc-ddd- amtlich-2014.pdf
  9. ↑ 9,0 9,1 9,2 9,3 VHitG. Arztbrief Auf Basis der HL7 Clinical Document Architecture Release 2 Für das deutsche Gesundheitswesen [Internet]. 2006 Sep 27 [aktualisiert 2012 Jun 18; abgerufen 2014 May 31]. Verfügbar unter: http://wiki.hl7.de/index.php/IG:Arztbrief_2006
  10. ↑ R-MIM-Refined Message Information Models [Internet]. Corepoint Health; [abgerufen 2014 Aug 29]. Verfügbar unter: http://www.corepointhealth.com/resource- center/hl7-resources/r-mim-refined-message-information-model
  11. ↑ 11,0 11,1 Boone, Keith W. The CDA Book. London: Springer-Verlag; 2011
  12. ↑ Kassner, Andreas. IHE Integrationsprofil XDS.b. [Internet]. [abgerufen 2014 July 30]. Verfügbar unter: http://devel.ztg-nrw.de/ZTG/content/e35/e6520/ e8126/ lecture_downloads8132/ object8136/FolienKassner_ger.pdf
Abgerufen von „https://wiki.hl7.de/index.php?title=Cdapueb:Grundlagen&oldid=22075“