Konzept-Modellbeschreibung

Aus Hl7wiki
(Teildokument von Arztbrief 2.x)
Wechseln zu: Navigation, Suche
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 Release 2 – Konzept und Modellbeschreibung

CDA und XML

Für XML als grundsätzliches Format spricht die Flexibilität nicht nur bei der Länge einzelner darzustellender Texte sondern auch bezüglich der a priori nicht begrenzten Schachtelungstiefe von Elementen.

HL7 als IT-Standard im Gesundheitswesen ist vornehmlich in Krankenhäusern verbreitet und wird zum Datenaustausch zwischen Abteilungssystemen eingesetzt. Der ursprünglich aus Amerika stammende Ansatz ist im Laufe der Zeit zu einem international einsetzbaren Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken. Mittlerweile wird HL7 in vielen Ländern konkret eingesetzt, ist in manchen Ländern sogar offizielle Norm. Dennoch wurde HL7 in Deutschland im niedergelassenen Bereich oder in der ambulant-stationären Kommunikation bisher nicht umgesetzt.

Zwischenzeitlich ist von der HL7-Organisation der Standard „HL7 v3" international entwickelt und anerkannt worden (bzw. abhängig von den Anwendungsdomänen noch in Verabschiedung und Anerkennung). HL7 v3 bietet:

  • eine konzeptuelle Grundlage in einem gemeinsamen, umfassenden „Reference Information Model" (RIM) für alle Teile von HL7 v3; dieses RIM ist ANSI- und ISO-Standard
  • ein festes semantisches Fundament in explizit definierten Konzept-Domänen
  • ausgewählte standardisierte Terminologien, die in den Domänen semantische Interoperabilität garantieren
  • die Trennung von Inhalten und Syntax (wenngleich die Verwendung bestimmter Elementnamen vor allem im Header eine gewisse Semantik suggerieren)
  • eine technologie-unabhängige Entwurfsmethodik.

HL7 v3 basiert auf XML und wird genutzt für die Übermittlung von Nachrichten. HL7 stellt außerdem einen Standard zur Strukturierung, zum Inhalt und zum Austausch medizinischer Dokumente, der so genannten Clinical Document Architecture (CDA), zur Verfügung. Dabei steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund, ist also nicht beschränkt auf Krankenhäuser. Als Grundlage für die Dokumente wurde HL7 Version 3 CDA Release 2 gewählt.

CDA Standard

Die Clinical Document Architecture[1] ist ein Standard für den Austausch und die Speicherung von klinischer Dokumentation, wie zum Beispiel ein Entlassbrief oder eine Überweisung, Behandlungsdokumentation oder OP-Berichte. Dabei wird die Extensible Markup Language XML[2] benutzt. CDA wird entwickelt von HL7 (Health Level Seven), einer bedeutenden internationalen Organisation für die Entwicklung von IT-Standards für das Gesundheitswesen.

CDA ist eine Entwicklung innerhalb der HL7-Gruppe seit 1997 und stellt einen XML-basierten Dokumenten-Markup Standard zur strukturierten klinischen Dokumentation zur Verfügung. Es definiert ein Informationsobjekt, das außerhalb einer Nachricht existieren kann und neben (strukturiertem) Text auch Bilder, Töne, Biosignale usw. enthalten bzw. referenzieren kann. CDA ist Teil der so genannten „Familie" der HL7 Version 3 Standards. Die erste Version, CDA Release 1, konnte bereits im September 2000 als offizieller Standard verabschiedet werden (CDA Level One ANSI/HL7 CDA R1.0-2000). Damit galt CDA R1 als erster offizieller XML-basierter Standard im Gesundheitswesen. Mittlerweile wird Release 1 in unzähligen Projekten rund um die Welt genutzt. Auf zwei internationalen Konferenzen 2002 und 2004 wurden die verschiedenen Projekte dargestellt (siehe Proceedings[3] [4]). Die Erfahrungen und weiter gehende Bedürfnisse sind in die Entwicklung von CDA Release 2 eingegangen.

CDA Release 2 als Fortentwicklung dieses Standards wurde, nach beinahe fünf Jahren weiterer Entwicklungsarbeit am Standard, im Juli 2005 zum ANSI Standard erhoben. In diese Entwicklungen sind zahlreiche Erfahrungen aus weltweit mehr als 15 größeren, teilweise nationenweiten Projekten eingeflossen, die sich intensiv um CDA Release 1 und der Weiterentwicklung verdient gemacht haben. Basierend auf dem HL7 Referenz-Informationsmodell (siehe oben) besteht CDA Release 2, grob gesprochen, aus Tags/Markup, die Semantik bereitstellen für Personen und Dokumenteneigenschaften (z. B. <patient>, <provider>, <authenticator>, etc.) und für die Abbildung von Dokumentenstrukturen und -hierarchien genutzt werden können (z. B. <section>, <paragraph>, <table>, etc.).

Der Name für dieses Konzept änderte sich – aus der ursprünglichen Kona-Architektur wurde die Patient Record Architecture und dann schließlich die Clinical Document Architecture – aber die Ideen dieser Architektur sind gleich geblieben.

Ein wichtiges Konzept in CDA ist das der Level, die a.a.O. weiter erläutert werden (siehe unten in diesem Leitfaden).

Eigenschaften von CDA Dokumenten

Im Standard werden sechs Kerneigenschaften definiert, die ein klinisches Dokument nach CDA kennzeichnen. Diese seien hier im Folgenden eingehender erläutert.

Persistenz

CDA Dokumente sind Persistenz, das heißt dauerhaft Existent in den sendenden oder empfangenden Systemen. Dies kennt man auch aus der Papierwelt (klinische Dokumentation hat „Dokumenten-Charakter").

Verantwortlichkeit für die Verwaltung des Dokuments

Eine Organisation ist verantwortlich für die Verwaltung eines CDA Dokuments.

Signaturfähigkeit

Ein CDA Dokument ist durch Informationen gekennzeichnet, die potentiell signiert werden können bzw. zur vor dem Gesetz gültigen Signatur benutzt werden können. (vgl. [5])

Kontext

Alle Informationen werden in Dokumenten in einen bestimmten Kontext gestellt. Ein Entlassbrief fasst z. B. alle Informationen der vorangegangenen Behandlungsepisode im Kontext der Entlassung zusammen. Diese Kontextbewahrung gilt für das ganze Dokument.

Ganzheit des Dokuments

Der Inhalt eines klinischen Dokuments bezieht sich immer auf das Dokument als Ganzes, Teilinformationen daraus können nicht ohne Bezug auf das Dokument verwendet werden.

Lesbarkeit (human readability)

Jedes CDA Dokument muss die klinischen Informationen in lesbarer Form enthalten. Diese Lesbarkeit der klinischen Inhalte für die menschlichen Kommunikationspartner ist dadurch gewährleistet, dass man diesen Anteil im XML Dokument mit sehr einfachen Mitteln (z. B. so genannte Stylesheets) sichtbar machen kann. Dies betrifft sowohl den CDA-Body als auch die strukturierten Informationen im CDA-Header. Dafür gilt zudem:

  • Es muss einen deterministischen Weg für einen Empfänger geben, den authentifizierten Inhalt sichtbar, sprich für lesbar zu machen.
  • Die Lesbarkeit sollte nicht beinhalten, dass ein bestimmtes Stylesheet zusammen mit dem CDA Dokument gesendet werden muss. Es muss möglich sein, den Inhalt mit einem geeigneten Stylesheet und marktüblichen Browsern darzustellen.
  • Lesbarkeit bezieht sich auf den authentifizierten Inhalt. Zusätzlich kann weitere Information im Dokument vorhanden sein, die auf Auswertbarkeit durch Anwendungssysteme abzielt, die aber nicht lesbar dargestellt werden muss.
  • Wenn strukturierter Inhalt vom narrativen Text abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde, z. B. durch den Autor, durch eine Person, die die Codes hinzugefügt hat, durch automatisierte Verarbeitung der natürliche Sprache, durch eine spezifische Software.
  • Wenn narrativer Text von strukturierter Information abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde.

CDA Modellbeschreibung

Wie alle Spezifikationen von Nachrichten in HL7 basiert auch die Clinical Document Architecture auf dem RIM und ist als HL7 V3 Modell repräsentiert.

Grob gesprochen besteht ein CDA Dokument aus einem Header und einem Body, der wiederum Body Structures und CDA Entries aufweist. An die Entries können externe Referenzen (External References) geknüpft sein. Der folgende Überblick zeigt die Hauptkomponenten des CDA R2 Modells auf, in der Abbildung 3 ist das Ganze in XML-artiger Darstellung gezeigt.

Cdaab1 uebersicht.jpg

Cdaab1 uebersicht.jpg

[Abbildung 1] Vereinfachte Übersicht über einen Teil des CDA Modells mit Clinical Document Header (Informationen über das Dokument sowie deren Beteiligte, einschließlich Patient), Body Structures (Abschnitte und narrativer Text), CDA Entries (maschinenauswertbare Detailinformationen). Schließlich können auch externe Referenzen aufgeführt sein.

Cdaab1 xml gesamt.jpg

Cdaab1 xml gesamt.jpg

[Abbildung 2] Grober Aufbau eines CDA Dokuments aus XML Sicht.

CDA Header

Die Informationen zum Patienten, zum Dokument selbst, zu den weiteren beteiligten Personen und Organisationen sowie der dokumentierten Episode (Zeitereignisse) sind zum CDA Header zusammengefasst, hochstrukturiert und von der Semantik her festgelegt.

Die Informationen im Header unterstützen einen Austausch klinischer Dokumente über Institutionsgrenzen hinweg. Er trägt Informationen über das Dokument selbst (eine eineindeutige Identifikation, der Typ des Dokuments), über „Teilnehmer" am Dokument (an der Dokumentation beteiligte Heilberufler, Autoren, und natürlich den Patienten selbst), sowie über Beziehungen zu Dokumenten (zu Anforderungen und anderen Dokumenten). Mit den Informationen des Headers werden Dokumentenmanagement-Systeme unterstützt, der Header stellt dafür entsprechende Metadaten zur Verfügung. Schließlich hat man mit den im CDA Header verfügbaren Informationen die Zusammenführung einer individuellen (lebenslangen) Patientenakte vor Augen.

CDA Body

Die eigentliche klinische Dokumentation wird im so genannten CDA Body festgehalten. Im Vordergrund steht hier „lesbarer" (narrativer) Text, der verpflichtender Bestandteil von CDA R2 Dokumenten ist und die Interoperabilität zwischen den menschlichen Kommunikationspartnern garantiert.

Hier sind Möglichkeiten gegeben, diesen Text grob zu strukturieren, wie man dies von den Möglichkeiten der Textverarbeitung her kennt. Zur Strukturierung stellt die Standardspezifikation eine Reihe von XML-Elementen zur Verfügung, die als Body Structures zusammengefasst werden können. Der Body enthält ein oder mehrere Abschnitte (sections). Diese können auch ineinander geschachtelt sein, so wie Kapitel und Unterkapitel in einem Buch. Zudem sind Strukturierungen im Sinne von Tabellen oder Listen möglich.

  • Abschnitte <section>
  • Paragrafen <paragraph>
  • Kennzeichnung von bestimmten Inhalten <content>
  • Überschriften <caption>
  • Tabellen <table>
  • Listen <list>

Sections enthalten immer einen narrativen Block und erfüllen damit eine der oben genannten Maximen von CDA: die Mensch-zu-Mensch-Interoperabilität, die Lesbarkeit der Informationen für den Menschen. Im narrativen Block, durch das Textattribut in der section-Klasse repräsentiert, wird eingebetteter Text innerhalb eines Abschnittes angegeben. Dabei kann mit oben genanntem <content> Element bestimmter Inhalt gesondert gekennzeichnet werden. Zusammengefasst werden im Textblock (teils so auch schon in CDA Release 1 realisiert) u.a. folgende Möglichkeiten der Struktur- und Formgebung des fließenden Textes gegeben:

  • Zeilenumbrüche
  • Stilistische Angaben (unterstreichen, fett, kursiv etc.)
  • Hoch- und Tiefstellung von Text
  • Fußnoten
  • Symbole
  • Revisionsmarken im Text wie <delete>, <insert>

Mit den beschriebenen Body Strukturen können CDA Entries verbunden sein. Diese repräsentieren den „computerlesbaren Teil" innerhalb eines Dokumentenabschnitts. CDA Entries sind im Prinzip eine Auswahl aus Klassen mitsamt Attributen aus dem HL7 Referenz-Informationsmodell (RIM). In der folgenden Abbildung ist ein Ausschnitt daraus gezeigt.

Cdaab1 auswahlliste.gif

Cdaab1 auswahlliste.gif

[Abbildung 3] Ausschnitt aus der Auswahlliste der CDA Body Entries mit Darstellung der HL7 RIM-Klassen und deren Attributen

Diese Auswahlliste von Aktivitäten wird auch als Clinical Statement Pattern bezeichnet und findet sich in gleicher oder ähnlicher Form auch in HL7-Version 3-Nachrichten zu Anforderungen und Befunden etc. wieder. Eine konkrete Ausprägung davon wird dann als Clinical Statement bezeichnet. In dieser Auswahl sind folgende Klassen verfügbar:

  • observation, eine (kodierte) Beobachtung, z. B. ein Befund oder eine Diagnose
  • procedure, eine Prozedur, z. B. eine Operation, eine andere Behandlung, rein diagnostischer Eingriff
  • encounter, Angaben zu früheren, jetzigen oder geplanten Patientenkontakten
  • substanceAdministration, medikamenten-bezogene Angaben im Sinne von stattgefundenen (Medikamentenanamnese) oder geplanten Medikamentengaben
  • supply, zur Verfügungstellung von Material oder Medikamentenverabreichungen
  • organizer, zur Gruppierung von anderen CDA Entries (Batterien, Cluster)
  • observationMedia, multimedialer Inhalt als Teil des Dokuments
  • regionOfInterest, Kennzeichnung einer Hervorhebung eines Teilaspekts eines Bildes.

Alle diese Entries können untereinander linear oder rekursiv hierarchisch verbunden sein. Es sind gleichstufige Beziehungen möglich (zum Beispiel eine Liste von Beobachtungen), aber auch die Wiedergabe einer Hierarchie (z. B. „kleines Blutbild", bestehend aus „Erythrozyten", „Leukozyten",...).

Die folgende Abbildung zeigt das ganz CDA Release 2 Modell.

Cdaab1 cda rmim.jpg

Cdaab1 cda rmim.jpg

[Abbildung 4] Clinical Document Architecture Release 2.0

  1. HL7 v3 Clinical Document Architecture, Release 2.0 (ANSI Standard CDA Release 2, Juli 2005), ISO/HL7 27932:2009 Data Exchange Standards -- HL7 Clinical Document Architecture, Release 2
  2. World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition. http://www.w3.org/TR/REC-xml
  3. First international conference on CDA, Berlin 2002. Konfe-renz-Website und Proceedings http://www.hl7.de/cda2002
  4. Second International conference on CDA, Acapulco 2004. Konferenz-Website und Proceedings http://www.hl7.de/iamcda2004
  5. Referenzfehler: Es ist ein ungültiger <ref>-Tag vorhanden: Für die Referenz namens cdasign wurde kein Text angegeben.


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.