CDA-Header: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(→‎Grundlegende Struktur, XML)
 
(9 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
{{Underconstruction}}
+
== Einleitung ==
−
 
 
−
= Einleitung =
 
 
Als CDA-Header bezeichnet man den Teil eines [[Clinical Document Architecture (CDA)|CDA-Dokuments]], der sich außerhalb des eigentlichen Dokumenteninhaltes (CDA-Body) befindet.
 
Als CDA-Header bezeichnet man den Teil eines [[Clinical Document Architecture (CDA)|CDA-Dokuments]], der sich außerhalb des eigentlichen Dokumenteninhaltes (CDA-Body) befindet.
  
Zeile 15: Zeile 13:
 
* Empfänger einer Massnahme (Patient)
 
* Empfänger einer Massnahme (Patient)
  
−
== Standardisierung ==
+
=== Standardisierung ===
 
Die Nutzung der Daten im CDA-Header setzt voraus, dass die am Informationsaustausch Beteiligten gemeinsame Regeln für Struktur und Bedeutung der Headerdaten festlegen und einhalten.
 
Die Nutzung der Daten im CDA-Header setzt voraus, dass die am Informationsaustausch Beteiligten gemeinsame Regeln für Struktur und Bedeutung der Headerdaten festlegen und einhalten.
  
Zeile 22: Zeile 20:
 
<ref>CDA-CH: Spezifikation zum elektronischen Austausch von medizinischen Dokumenten in der Schweiz, Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2
 
<ref>CDA-CH: Spezifikation zum elektronischen Austausch von medizinischen Dokumenten in der Schweiz, Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2
 
Etappe 1, Version 1.2, 27. Januar 2009 http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH_de_V1.2.pdf</ref>
 
Etappe 1, Version 1.2, 27. Januar 2009 http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH_de_V1.2.pdf</ref>
 +
<ref>CDA-CH-II: SPEZIFIKATION ZUM ERSTELLEN VON VORLAGEN FÜR DIE HEALTH LEVEL 7 CLINICAL DOCUMENT ARCHITECTURE, Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2
 +
Etappe 2, Version 1.2a (genehmigt), 01. Oktober 2011, http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH-II_de_V1.2a.pdf</ref>
 
<ref>ELGA Gesundheitsdaten: Allgemeiner Implementierungsleitfaden für CDA Dokumente
 
<ref>ELGA Gesundheitsdaten: Allgemeiner Implementierungsleitfaden für CDA Dokumente
−
CDA Dokumente im österreichischen Gesundheitswesen, Version: 2.00, 10.10.2011 http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Harmonisierungsarbeit/ELGA_CDA_Allgemein_2.00_FWGD.pdf</ref>
+
CDA Dokumente im österreichischen Gesundheitswesen, Version: 2.01a, 18.04.2013
 +
http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Harmonisierungsarbeit/upload220413/HL7_Implementation_Guide_for_CDA_R2_-_Allgemeiner_Implementierungsleitfaden_fuer_ELGA_CDA_Dokumente_V2.01a.pdf</ref>
 +
<ref>ELGA CDA Implementierungsleitfäden, Version: 2.01a (Final), HL7 Implementation Guide for CDA® R2: Entlassungsbrief (Ärztlich) http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Harmonisierungsarbeit/upload220413/HL7_Implementation_Guide_for_CDA_R2_-_Entlassungsbrief_AErztlich_V2.01a.pdf
 +
</ref>
 
. Auch auf internationaler Ebene werden Beschreibungen und Festlegungen für den CDA-Header erarbeitet, abgestimmt und veröffentlicht. Wichtige Spezifikationen in diesem Zusammenhang sind:
 
. Auch auf internationaler Ebene werden Beschreibungen und Festlegungen für den CDA-Header erarbeitet, abgestimmt und veröffentlicht. Wichtige Spezifikationen in diesem Zusammenhang sind:
 
* Smart Open Services for European Patients <ref name="epSOS-352C">epSOS Work Package 3.5 - Semantic Services, Appendix C, D3.5.2, Version: 0.0.7, 2010-5-31</ref>
 
* Smart Open Services for European Patients <ref name="epSOS-352C">epSOS Work Package 3.5 - Semantic Services, Appendix C, D3.5.2, Version: 0.0.7, 2010-5-31</ref>
Zeile 34: Zeile 37:
 
Das zuletzt genannte Dokument versucht, die Vorgaben aus verschiedenen anderen Spezifikationen zusammenzuführen und zu vereinheitlichen, zu "konsolidieren". Zwar berücksichtigt diese Konsolidierung zunächst die Anforderungen der US-amerikanischen Anwender, die Vorgehensweise zeigt aber einen möglichen Weg auf, um in ähnlicher Weise die Anforderungen anderer Nutzerkreise zusammenzuführen - etwa im deutschsprachigen Raum oder für den europäischen Markt.
 
Das zuletzt genannte Dokument versucht, die Vorgaben aus verschiedenen anderen Spezifikationen zusammenzuführen und zu vereinheitlichen, zu "konsolidieren". Zwar berücksichtigt diese Konsolidierung zunächst die Anforderungen der US-amerikanischen Anwender, die Vorgehensweise zeigt aber einen möglichen Weg auf, um in ähnlicher Weise die Anforderungen anderer Nutzerkreise zusammenzuführen - etwa im deutschsprachigen Raum oder für den europäischen Markt.
  
−
= Elemente des Headers =
+
== Links ==
−
== Form und Inhalt, Struktur und Bedeutung des Dokumentes ==
+
* [[CDA-Body]]
−
Eineindeutige Identifikation, eine Andeutung des Typs des Dokuments, Sprache, Versionierung.
 
−
 
 
−
=== Grundlegende Struktur, XML ===
 
−
Namespaces, CDA-Schema, Encoding, HL7 V3 typeId
 
−
 
 
−
=== Dokumenttyp ===
 
−
Über das ''code'' Modellattribut der ClinicalDocument Klasse wird eine Typisierung
 
−
des Dokuments vorgenommen.
 
−
 
 
−
Zur eindeutigen Identifikation der Typisierung wird das Codesystem LOINC
 
−
(Logical Observation Identifiers Names and Codes [LOINC]) verwendet.
 
−
Im XML @code Attribute steht der eigentliche Code, @codeSystem ist die
 
−
OID des LOINC Systems (2.16.840.1.113883.6.1).
 
−
 
 
−
Der optionale @displayName kann die klartextliche Bedeutung wiedergeben,
 
−
darf aber von der empfangenden Anwendung selbst nicht ausgewertet
 
−
werden.
 
−
Es ist zu beachten, dass eine Klassifikation des Inhalts in diesem Sinne in
 
−
der Regel auch Inhaltsanforderungen vorgibt. So können Anwendungsszenarien
 
−
für CDA dahin gehend definiert werden, dass bestimmte
 
−
Teile darin vorkommen müssen, damit das CDA „gültig“ ist (siehe auch [[CDA-Template]]s).
 
−
 
 
−
<syntaxhighlight lang="xml">
 
−
<code code="34105-7" codeSystem="2.16.840.1.113883.6.1"
 
−
displayName="Zusammenfassung bei stationärer Entlassung"/>
 
−
</syntaxhighlight>
 
−
 
 
−
{{NoteBox|Zu diesem Punkt siehe auch die aktuellen Arbeiten auf der Seite [[Dokumenttypen]]. }}
 
−
 
 
−
== Patient ==
 
−
Identifikation, Stammdaten
 
−
 
 
−
== Beteiligte Personen und Organisationen ==
 
−
Weitere "Teilnehmer" am Dokument (an der Dokumentation beteiligte Heilberufler, Autoren, Empfänger).
 
−
 
 
−
== Zeitereignisse, dokumentierte Episode, Fall ==
 
−
 
 
−
== Beziehungen zu anderen Dokumenten ==
 
−
 
 
−
= Modellierung =
 
−
CDA basiert in weiten Teilen auf HL7 Version 3. Deshalb gelten für Struktur und Inhalt eines CDA Dokuments grundsätzliche Regeln, die sich drei unterschiedliche Ebenen zuordnen lassen:
 
−
* Klassen - Datenstrukturen, die Objekte und deren Beziehungen beschreiben. Objekte haben einen "Lifecycle", sie können sich also im Laufe der Zeit verändern. Die Eigenschaften einer Klasse werden durch die Werte ihrer Attribute festgelegt. Objekte repräsentieren
 
−
** Aktivitäten (Act) - jede medizinische Dokumentation ist mit "Aktivität" verbunden
 
−
** Entitäten, die in einer Beziehung zu einer Aktivität stehen (Entity)
 
−
** die Rollen, in denen die Entitäten im Kontext der Aktivität auftreten oder verwendet werden
 
−
** die Beteiligung der Entitiät (in ihrer jeweiligen Rolle) an einer Aktivität
 
−
* Datentypen - Datenstrukturen für die Werte von Attributen. Datentypen repräsentieren den Wert eines Attributes. Eine solche Repräsentation kann in sich wiederum strukturiert sein, also weitere Attribute besitzen. Ein Attribut kann sich zwar ändern, einen anderen Wert annehmen - der Wert selbst hat aber keinen "Lifecycle" oder veränderlichen Status.
 
−
* Vokabular und Identifikatoren - Für Werte, die in kodierter Form auftreten, werden bestimmte Regeln festgelegt. Die Konzepte, die durch Codes repräsentiert werden, können ihrerseits wiederum komplexe Beziehungen zu anderen Konzepten haben (diese Beziehungen liegen dann aber außerhalb des hier beschriebenen formalen Modells).
 
−
 
 
−
== Klassen ==
 
−
Wie für alle anderen CDA-Strukturen basieren auch die im CDA-Header verwendeten Strukturen auf dem RIM. Ein CDA-Dokument stellt eine Aktivität "ClinicalDocument" dar. Das CDA-Modell legt die formale Struktur fest, in die alle weiteren Strukturen (Klassen, Beziehungen, Attribute, Codes) in einem CDA-Dokument eingeordnet sind. Die Repräsentation dieser Strukturen als XML wird von der XML-ITS beschrieben <ref>XML Implementable Technology Specification for V3 Structures</ref>.
 
−
 
 
−
== Datentypen ==
 
−
CDA verwendet die Datentypen von HL7 Version 3. Die Repräsentation dieser Strukturen als XML wird von der XML-ITS beschrieben <ref>XML Implementation Technology Specification - Data Types</ref>
 
−
 
 
−
== Codesysteme und Value Sets==
 
−
 
 
−
HL7 Vocabulary legt Regeln für den Umgang mit kodierten Werten fest. Diese Regeln werden zusammengefasst dargestellt in den "Core Principles". Für kodierte Werte wird der Datentyp CD (Concept Descriptor) oder ein davon abgeleiteter Datentyp verwendet. Für jedes codierte Attribut innerhalb des CDA-Modells und seiner Unterstrukturen muss festgelegt werden, welche Codewerte für dieses Attribut zulässig sind. Diese Festlegung wird als "vocabulary binding" bezeichnet. HL7 kennt dabei zwei grundsätzliche Vorgehensweisen für das "Binden" von ausgewählten kodierten Konzepten an ein bestimmtes Attribut im Modell: "Context Binding" und "Model Binding".
 
−
 
 
−
=== Vorgehensweise für "Context Binding": ===
 
−
 
 
−
==== RIM: ====
 
−
Im RIM oder in einem vom RIM abgeleiteten Modell wird einem Attribut eine "ConceptDomain" zugeordnet. Die Beschreibung der ConceptDomain legt genau fest, welche Art von Konzepten als Wert für dieses Attribut in Frage kommt.
 
−
* Beispiel: Participation.functionCode verwendet die Concept Domain ''ParticipationFunction''
 
−
Bei der Verfeinerung des Modells und/oder der Anpassung an einen bestimmten Verwendungszweck wird die ConceptDomain dann zur Grundlage einer genaueren Beschreibung und/oder zur Festlegung bestimmter Codewerte, die in diesem Zusammenhang hier zulässig sein sollen. 
 
−
* Beispiel: Im HL7 Vocabulary gibt es als Spezialisierung von ParticipationFunction u.a. die Concept Domain ''AuthorizedParticipationFunction''.
 
−
 
 
−
==== Codesysteme ====
 
−
Für viele der von HL7 definierten ConceptDomains sind von HL7 Codesysteme entwickelt worden, in denen zur ConceptDomain passende Konzepte und Codes enthalten sind. Jedes Codesystem ist durch eine eindeutige OID gekennzeichnet, dadurch wird durch Angabe von Code und OID ein bestimmtes Konzept eindeutig bezeichnet.
 
−
 
 
−
* Beispiel: Als Codesystem für die Concept Domain ParticipationFunction steht im HL7 Vocabulary zur Verfügung: ParticipationFunction [2.16.840.1.113883.5.88]
 
−
 
 
−
 
 
−
=== Vorgehensweise für "Model Binding": ===
 
−
Alternativ dazu kann auch direkt eine spezielle Auswahl von Codes an ein Attribut in einem Modell gebunden werden ("Model Binding"). Dies geschieht z.B. für Attribute, die die Bedeutung von Objekten, ihren Status und ihr Verhalten beschreiben, sofern dies für die Konsistenz des Modells erforderlich ist (structural attributes).
 
−
 
 
−
==== Value Sets ====
 
−
Die Festlegung der zulässigen Menge von Codes für ein bestimmtes "Binding" erfolgt in beiden Fällen (Context Binding und Model binding) über eine "Value Set Assertion". Dadurch werden Codes aus einem oder mehreren Codesystemen ausgewählt, eine solche Auswahl stellt ein "Value Set" dar. Dabei wird u.a. angegeben, welche Codes bei der Implementierung unterstützt werden müssen, welche Codes unterstützt werden dürfen und welche Codes nicht verwendet werden dürfen. Jedem Value Set wird wiederum eine OID zur eindeutigen Referenzierung zugeordnet.
 
−
* Beispiel: Verschiedene im HL7 Vocabulary definierte ValueSets verwenden Codes aus dem Codesystem ''ParticipationFunction'', u.a.
 
−
** AuthorizedParticipationFunction  [2.16.840.1.113883.1.11.19929]
 
−
** AuthorizedReceiverParticipationFunction  [2.16.840.1.113883.1.11.19932]
 
−
 
 
−
ACHTUNG: Die OID des Value Sets dient nur der Referenzierung des Value Sets, sie ersetzt ''nicht'' die OID des Codesystems. Die Bedeutung eines kodierten Konzepts ergibt sich immer aus der Kombination Code/Codesystem. (So kann ein ValueSeet theoretisch mehrere gleichlautende Codes enthalten, die aber zu verschiedenen Codesystemen gehören!)
 
−
 
 
−
==== Binding ====
 
−
Die eigentliche Festlegung, das "Binding" beschreibt dann die Zuordnung eines Value Sets zu einem bestimmten Attribut. Durch diese formale Vorgehensweise wird sichergestellt, dass
 
−
* Modelle und Teile von Modellen als Struktur wiederverwendbar sind, unabhängig davon, welche Konzepte oder Codesysteme bei der Implementierung letzlich zum Einsatz kommen.
 
−
* Konzepte und ihre Codierung wiederverwendbar sind (und somit nicht für jede Verwendung des Konzeptes in einem anderen Zusammenhang wieder eine neue Codetabelle samt Code und Bedeutung des Konzeptes spezifiziert werden muss)
 
−
* Validierung von Datenstrukturen und Codes gegen die für den speziellen Fall festgelegten ValueSets möglich ist
 
−
 
 
−
== Identifikatoren ==
 
−
Identifikatoren dienen der eindeutigen Identifikation und Referenzierung eines Objekts. Wenn Ersteller (Sender) und Nutzer (Empfänger) der Information über hinreichende Information verfügen, reicht es für viele Anwendungsfälle aus, einen Identifikator zu senden, anstatt die vollständige verfügbare Information zu einem Objekt in einer Datenstruktur wiederzugeben.
 
−
 
 
−
Für Identifikatoren wird der Datentyp II (Instance Identifier) verwendet. Die Werte der Attribute ''root'' und ''extension'' müssen zusammengenommen einen weltweit eindeutigen Wert ergeben, der die Instanz identifziert. ''root'' stellt also den "Namespace" dar, innerhalb dessen ''extension'' eindeutig ist (z.B. Identifikationsschema, Assiging authority etc.). Der Wert von ''root'' muss entweder ein OID (ISO Object Identifier) oder ein UUID (DCE Universally Unique Identifier) sein. Falls der Wert in ''root'' alleine schon eindeutig ist (z.B. wenn das Objekt durch eine OID identifiziert ist), so wird ''extension'' weggelassen.
 
  
−
Für jedes Attribut, das einen Identifikator darstellt, können in der Spezifikation Festlegungen getroffen werden. Beispielsweise kann ein bestimmter Namespace (''root'') gefordert werden, oder die Verwendung einer OID vorgeschrieben sein.
+
== Literatur ==
 +
* [[CDA und HL7 V3]]
 +
* [[Codesysteme und Value Sets]]
  
−
= Referenzen =
+
== Referenzen ==
 
<references/>
 
<references/>

Aktuelle Version vom 21. Mai 2013, 10:05 Uhr

Einleitung

Als CDA-Header bezeichnet man den Teil eines CDA-Dokuments, der sich außerhalb des eigentlichen Dokumenteninhaltes (CDA-Body) befindet.

Der CDA-Header enthält Informationen, die (weitgehend) unabhängig vom spezifischen Inhalt des Dokuments sind (Metadaten für medizinische Dokumente)). Diese Daten können z.B. für die Unterstützung folgender Zwecke verwendet werden:

  • Austausch von medizinischen Dokumenten zwischen Institutionen,
  • das Management dieser Dokumente und
  • die Zusammenstellung der einem einzelnen Patienten zugehörigen Dokumente im Sinne einer lebensbegleitenden Patientenakte zu ermöglichen.

Im CDA-Header eines CDA-Dokuments sind u.a. folgende Informationen enthalten:

  • Informationen zum Dokument und zum Workflow (Sender und Empfänger)
  • Daten zum Ereignis, das dokumentiert wird
  • Akteure einer Massnahme (z.B. Ärzte)
  • Empfänger einer Massnahme (Patient)

Standardisierung

Die Nutzung der Daten im CDA-Header setzt voraus, dass die am Informationsaustausch Beteiligten gemeinsame Regeln für Struktur und Bedeutung der Headerdaten festlegen und einhalten.

In verschiedenen Implementierungsleitfäden im deutschen Sprachraum werden detaillierte Angaben zum CDA-Header gemacht [1] [2] [3] [4] [5] . Auch auf internationaler Ebene werden Beschreibungen und Festlegungen für den CDA-Header erarbeitet, abgestimmt und veröffentlicht. Wichtige Spezifikationen in diesem Zusammenhang sind:

  • Smart Open Services for European Patients [6]
  • IHE PCC Medical Documents Specification (1.3.6.1.4.1.19376.1.5.3.1.1.1)
  • HL7 Implementation Guide for CDA Release 2: History and Physical (H&P) Notes (U.S. Realm) DSTU Release 1, 2008-07-16
  • ASTM/HL7 Continuity of Care Document (CCD)
  • HITSP C83
  • HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1 (DSTU December 2011)

Das zuletzt genannte Dokument versucht, die Vorgaben aus verschiedenen anderen Spezifikationen zusammenzuführen und zu vereinheitlichen, zu "konsolidieren". Zwar berücksichtigt diese Konsolidierung zunächst die Anforderungen der US-amerikanischen Anwender, die Vorgehensweise zeigt aber einen möglichen Weg auf, um in ähnlicher Weise die Anforderungen anderer Nutzerkreise zusammenzuführen - etwa im deutschsprachigen Raum oder für den europäischen Markt.

Links

Literatur

Referenzen

  1. ↑ Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen, Implementierungsleitfaden, Version 1.50, 12.05.2006 http://www.bvitg.de/arztbrief.html?file=tl_files/public/downloads/publikationen/arztbrief/Leitfaden-VHitG-Arztbrief-v150.pdf
  2. ↑ CDA-CH: Spezifikation zum elektronischen Austausch von medizinischen Dokumenten in der Schweiz, Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2 Etappe 1, Version 1.2, 27. Januar 2009 http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH_de_V1.2.pdf
  3. ↑ CDA-CH-II: SPEZIFIKATION ZUM ERSTELLEN VON VORLAGEN FÜR DIE HEALTH LEVEL 7 CLINICAL DOCUMENT ARCHITECTURE, Basierend auf der HL7 Clinical Document Architecture (CDA), Release 2 Etappe 2, Version 1.2a (genehmigt), 01. Oktober 2011, http://www.hl7.ch/fileadmin/ungeschuetzte_dateien/files_tc/CDA-CH-II_de_V1.2a.pdf
  4. ↑ ELGA Gesundheitsdaten: Allgemeiner Implementierungsleitfaden für CDA Dokumente CDA Dokumente im österreichischen Gesundheitswesen, Version: 2.01a, 18.04.2013 http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Harmonisierungsarbeit/upload220413/HL7_Implementation_Guide_for_CDA_R2_-_Allgemeiner_Implementierungsleitfaden_fuer_ELGA_CDA_Dokumente_V2.01a.pdf
  5. ↑ ELGA CDA Implementierungsleitfäden, Version: 2.01a (Final), HL7 Implementation Guide for CDA® R2: Entlassungsbrief (Ärztlich) http://www.elga.gv.at/fileadmin/user_upload/uploads/download_Papers/Harmonisierungsarbeit/upload220413/HL7_Implementation_Guide_for_CDA_R2_-_Entlassungsbrief_AErztlich_V2.01a.pdf
  6. ↑ epSOS Work Package 3.5 - Semantic Services, Appendix C, D3.5.2, Version: 0.0.7, 2010-5-31
Abgerufen von „https://wiki.hl7.de/index.php?title=CDA-Header&oldid=13139“