CDA-Header: Unterschied zwischen den Versionen
(→Grundlegende Struktur, XML) |
|||
| Zeile 39: | Zeile 39: | ||
=== Grundlegende Struktur, XML === | === Grundlegende Struktur, XML === | ||
| − | Namespaces, CDA-Schema, | + | Namespaces, Encoding, classCode, moodCode, CDA-Schema |
| + | |||
| + | realmCode, typeId, templateId, Templates | ||
=== Dokumenttyp === | === Dokumenttyp === | ||
Version vom 19. März 2012, 15:49 Uhr
 |
This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template. This article was last edited by Cgessner (talk| contribs) 12 years ago. (Purge) Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage. This article was last edited by Cgessner (talk| contribs) 12 years ago. (Purge) |
Inhaltsverzeichnis
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] . 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 [4]
- 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.
Elemente des Headers
Form und Inhalt, Struktur und Bedeutung des Dokumentes
Eineindeutige Identifikation, eine Andeutung des Typs des Dokuments, Sprache, Versionierung.
Grundlegende Struktur, XML
Namespaces, Encoding, classCode, moodCode, CDA-Schema
realmCode, typeId, templateId, Templates
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-Templates).
<code code="34105-7" codeSystem="2.16.840.1.113883.6.1"
displayName="Zusammenfassung bei stationärer Entlassung"/>
 |
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
Literatur
Weitere Informationen siehe: CDA und HL7 V3 und Codesysteme und Value Sets
Referenzen
- ↑ 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
- ↑ 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
- ↑ 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
- ↑ epSOS Work Package 3.5 - Semantic Services, Appendix C, D3.5.2, Version: 0.0.7, 2010-5-31
