Cdapueb:Grundlagen - Versionsgeschichte

Sschulz am 26. Januar 2015 um 12:38 Uhr

2015-01-26T12:38:50Z

Sschulz am 26. Januar 2015 um 11:40 Uhr

2015-01-26T11:40:12Z

Sschulz am 26. Januar 2015 um 11:24 Uhr

2015-01-26T11:24:26Z

Sschulz am 26. Januar 2015 um 11:22 Uhr

2015-01-26T11:22:28Z

Sschulz am 26. Januar 2015 um 11:19 Uhr

2015-01-26T11:19:28Z

Sschulz am 26. Januar 2015 um 11:16 Uhr

2015-01-26T11:16:28Z

Sschulz am 26. Januar 2015 um 11:15 Uhr

2015-01-26T11:15:34Z

Sschulz am 26. Januar 2015 um 11:09 Uhr

2015-01-26T11:09:56Z

Sschulz am 26. Januar 2015 um 11:07 Uhr

2015-01-26T11:07:42Z

Sschulz am 26. Januar 2015 um 11:07 Uhr

2015-01-26T11:07:07Z

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

← Nächstältere Version		Version vom 26. Januar 2015, 11:40 Uhr
Zeile 183:		Zeile 183:
	\|}		\|}
	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>:		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
		+	\|}

← Nächstältere Version		Version vom 26. Januar 2015, 11:24 Uhr
Zeile 182:		Zeile 182:
	\| Referenz		\| 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>:

← Nächstältere Version		Version vom 26. Januar 2015, 11:22 Uhr
Zeile 109:		Zeile 109:
	<br />		<br />
	Im folgenden werden die im Header und Body verwendeten Datentypen dargestellt und erläutert <ref name="Boone"/>:		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
		+	\|}

@@ Zeile 105: / Zeile 105: @@
 <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>Boone, Keith W. The CDA Book. London: Springer-Verlag; 2011</ref>.
+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" />.

@@ Zeile 69: / Zeile 69: @@
 • 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>VHitG. Arztbrief Auf Basis der HL7 Clinical Document Architecture Release 2 Für
+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>VHitG. Arztbrief Auf Basis der HL7 Clinical Document Architecture Release 2 Für
+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"

← Nächstältere Version		Version vom 26. Januar 2015, 11:09 Uhr
Zeile 107:		Zeile 107:
	<value xsi:type="CD" code="Code" codeSystem="System" codeSystemName="Name"/>		<value xsi:type="CD" code="Code" codeSystem="System" codeSystemName="Name"/>
	</syntaxhighlight>		</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>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>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>.

← Nächstältere Version		Version vom 26. Januar 2015, 11:07 Uhr
Zeile 104:		Zeile 104:
	<br />		<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:		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>

← Nächstältere Version		Version vom 26. Januar 2015, 11:07 Uhr
Zeile 102:		Zeile 102:
	\| PROC		\| 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: