Episode #9 – CDA – Clinical Document Architecture

Das Thema hast du schon gesagt, es geht um CDA. CDA ist die Clinical Document Architecture, und wir werden ganz kurz anreißen, was CDA ist. Renato wird ein bisschen erzählen, wer sich um CDA kümmert — ist das die HL7-Organisation, die das macht —, [wir] werden ganz kurz sagen, wo der Unterschied ist von CDA zu HL7 und FHIR. [Dann] schauen [wir] uns an, wie der Einsatz in Deutschland und in den USA ist, dann werden wir in medias res gehen und werden CDA erklären, ein bisschen technisch, [ich] hoff, es klappt, wenn man das einfach nur über Worte macht und nicht gleichzeitig was sieht. Und danach schauen wir noch mal, ob jetzt dieses eHealth-Gesetz vielleicht die Verbreitung von CDA befeuert oder aber nicht. Oder, Renato? — Immer ein guter Plan. — Wie schön. Spannender Plan. Ein interessanter Plan. 

Also was ist CDA? CDA steht für Clinical Document Architecture, und das ist eigentlich nichts anderes als ein elektronischer Arztbrief, der basiert auf XML. Dort gibt es einzelne Texte und unterschiedliche Level, und das reicht eigentlich schon. Also wenn man sich einfach nur sechs, sieben Wörter zu CDA speichern möchte, dann kann man sagen, dass es einfach eine Beschreibung [ist], wie ein elektronischer Arztbrief aussehen soll, und auch XML-basiert. 

Genau. Also wer ist für CDA verantwortlich, wer kümmert sich drum? Das ist die HL7-Organisation. Es ist eine internationale Organisation, die auch ihre Ableger hat, zum Beispiel in Deutschland und allen möglichen Ländern, die sich da engagieren. Die HL7-Organisation hat sich zum Ziel gesetzt, dass jeder auf seine Daten überall zugreifen kann, also vor allem, dass die Kommunikation zwischen den einzelnen Partnern innerhalb des Krankenhauses und des Gesundheitssystems reibungslos funktioniert. Und da hat die HL7 mit dem HL7-Standard, also mit dem Kommunikationsstandard, schon einen großen Beitrag geleistet. Neben dem HL7 V2 und HL7 V3 hat HL7 auch an der Entstehung von FHIR maßgeblich mitgewirkt und eben CDA, das, was wir heute besprechen, und auch die Arden-Syntax — also die Beschreibung von klinischen Pfaden — ist auf dem Mist von HL7 gewachsen. 

Genau, wir haben ja jetzt schon gesagt, wir wollen so ein bisschen rausarbeiten, wann HL7 V2 [Schrägstrich] V3 und wann CDA zum Einsatz kommen. Also HL7 kennen ganz viele Leute bestimmt aus dem Krankenhausbereich: Laborwerte werden über HL7 übertragen, oder Befundanforderungen werden über HL7 übertragen. Aber auch Ergebnisse, ICD-Codes, die ein System erstellt hat, [oder] Dokumente können auch über HL7 übertragen werden. Aber hier haben wir dann meistens den Nachteil, dass wir reine Textdokumente übertragen, ohne dass das andere System versteht, was in diesem Text drin ist. Und hier greift CDA ein. Also CDA fokussiert sich auf die Übertragung von Dokumenten, nicht so sehr die Übertragung von einzelnen Objekten, wie jetzt Befund, Laborwert oder Anforderungen, sondern bei CDA werden… — Renato, darf ich ganz kurz unterbrechen, das mit dem Text, das habe ich jetzt nicht verstanden, was meinst du mit Text? 

— Also in den Dokumenten, die über HL7 übertragen werden, kann man nicht reinschauen, das sind dann einfach nur… also da wird reiner Text übertragen, und das andere System — also der, der es liest, der kann das schon interpretieren, aber das andere System kann nicht in diesen Text reinschauen, kann nicht verstehen, was da drin steht. Und da liegt eben der Unterschied zwischen HL7 und CDA, beziehungsweise einer der vielen Unterschiede: CDA fokussiert sich sehr stark auf die Dokumente. Und da können auch noch Befunde übertragen werden und so weiter, aber das Ziel von CDA ist zum Beispiel, am Ende einer Behandlung den Arztbrief vom Krankenhaus an die Arztpraxis zu verschicken. Es gibt noch ein paar andere Use-Cases, wo man das gut verwenden kann, aber so der Hauptansatzpunkt wird wahrscheinlich das werden. Und hier ist es dann so, dass CDA wesentlich mehr Informationen überträgt und auch zur semantischen Interoperabilität — da haben wir das Wort wieder — zur semantischen Interoperabilität beitragen kann. Hier liegt ein Hauptunterschied zwischen diesen verschiedenen Standards. Und genau, wir schauen uns heute ja etwas näher dieses… — FHIR? — Ich würde vorschlagen, wir schauen uns CDA an, FHIR haben wir uns schon angeguckt. 

Ich mache einfach weiter mit dem Einsatz bisher in Deutschland und den USA. Und da muss man sagen, dass wir tatsächlich ein gutes Stück hinterherhängen. Die USA sind weiter, unter anderem auch wegen Obama und Obamacare. Nämlich Stichwort Meaningful Use: Da ist es so, dieses Ziel des Gesundheitswesens wird eben stark gefördert, und da ist CDA einer der Bausteine. Also dieses CDA, dieser elektronische Arztbrief, plus ein anderes Dokument, das Continuity of Care Document — das zusammen ist eine technologische Basis für Obamacare und Meaningful Use. Also [die USA sind] ein gutes Stück weiter. In Deutschland tun sich die Anbieter immer noch ein bisschen schwer, wobei, wenn man CDA mal richtig verstanden hat, ist es gar nicht so wahnsinnig kompliziert. [Es] gab in Deutschland ein altes Paper dazu, den VHitG-Arztbrief — selbst wenn der Verein inzwischen bvitg heißt, gibt es dieses Paper immer noch nur unter VHitG-Arztbrief —, [es] wurde aber inzwischen abgelöst. Also der bvitg, der Verband der Software-Hersteller im Gesundheitswesen, referenziert inzwischen auf diesen Arztbrief 2014/2015, der wiederum auch auf CDA basiert. Also der Verband der IT-Hersteller hat sich jetzt auch CDA verpflichtet. 

Genau, das Ganze ist auf jeden Fall im Kommen, wie [wir] schon gesagt [haben] — dass iOS jetzt sogar CDA im Betriebssystem direkt implementiert hat. Du wirst gleich noch ein bisschen was zum eHealth-Gesetz sagen, meiner Meinung nach eine sehr sinnvolle Geschichte, [mit der] man wunderbar Daten austauschen kann, und ich bin auch sicher, dass das jetzt in den nächsten fünf Jahren massiv an Fahrt aufnimmt. 

So, jetzt kommt wieder so eine Frage, Renato, die du nicht magst, aber ich stelle [sie] trotzdem: Renato, Komma, wie ist denn CDA aufgebaut? — Aha, fragst du etwa, weil du selbst nicht weißt, oder wie? — Nein, weil mir keine andere Überleitungsfrage eingefallen ist. — Okay, dann werde ich diese Frage mal beantworten. 

Also der CDA-Brief, der besteht aus einem Header und einem Body. Der Header ist das, was man vielleicht so als Umschlag betrachtet, dort steht drauf, wer den Arztbrief geschrieben hat. — Das Bild macht jeder immer. — Aber es ist gut, ja. — Ja, dann prügelt es sich vielleicht nach und nach ein. Es wäre auch mal gut, wenn sich einige Bilder verfestigen. — Also was steht auf dem Umschlag drauf? Auf dem Umschlag steht drauf, wer das Dokument geschrieben hat, aus welcher Institution das Ganze kommt, wer der Empfänger von diesem Brief ist. Was eigentlich nicht auf dem Umschlag drauf steht, ist der Patient — das wäre auch ziemlich undatenschützig —, aber trotzdem würde das auch im Header drin stehen. Also der Header enthält alle Metainformationen zu dem Brief, also die verantwortliche Organisation, der Arzt, der es geschrieben hat, der Empfänger, der Patient, alles, was so um dieses Dokument herum schwirrt. Und im Body steht dann der eigentliche Inhalt. Ich will da jetzt nicht zu viel vorwegnehmen, aber der Inhalt steht als Freitext und mit Annotations — aber da kommst du ja jetzt mit den Levels dazu. Hat diese Antwort was gebracht, Christian? 

Vielen Dank, Renato. Wir hatten vorher ausgemacht, dass du nichts [von] Annotations und Freitext sagst, ne? — Ja, ja, aber wir hatten [auch] ausgemacht, dass du mich nichts mehr fragst. — Also, kommen wir jetzt zu den Leveln. Da geistern dann tatsächlich sehr — hab ich mitbekommen — unterschiedliche Verständnisse von diesen Leveln durch die Gegend, das würde ich gerne jetzt mal klarziehen. Also Level 1 ist — und wir sprechen jetzt hier quasi nur vom Body, was ich jetzt erzähle, die Level beziehen sich nur auf den Body, der Header ändert sich nicht. Und [bei Level] 1 ist es so, dass wir Text haben, der Text kann auch formatiert sein, also kann irgendwie fett gedruckt sein, unterstrichen, hervorgehoben, könnte [eine Tabelle] drin sein, also so ein bisschen wie RTF. Das war es auch schon eigentlich an strukturierten Daten. Man bekommt also quasi einfach eine RTF-Datei und kann die über den Header vielleicht noch dem Patienten zuordnen. Man weiß jetzt aber nicht, ist das ein Entlassbrief, ist das vielleicht ein OP-Befund etc. Level 1 sollte von IT-Firmen dann wirklich sehr, sehr einfach umzusetzen sein. [Man legt] einfach den Text, den man exportieren möchte, unterhalb des Headers in den Body, und gut ist. Und dafür ist es ja auch gemacht worden, dass die Einstiegshürde sehr, sehr niedrig ist. 

Genau, darum wurden die Level gemacht, dass man erstmal mit Level 1 einsteigen kann und sich nachher hocharbeitet bis Level 3. Also Level 1: man kann Texte austauschen, man kann die automatisch Patienten zuordnen, das war es dann aber auch schon. Level 2 geht ein bisschen weiter, also die gleichen Informationen wie Level 1, man kann aber zusätzlich strukturierte Informationen hinzufügen. Die beziehen sich jetzt aber weniger auf die konkreten Daten, also Diagnosen, Prozeduren, welche Medikamente, sondern [auf die Frage], was für eine Art Dokument übermitteln wir gerade. Das heißt, es kann eben gesagt werden, wir haben einen Entlassbrief hier. Und dieser Entlassbrief ist dann codiert. Und man kann sagen, im Entlassbrief gibt es eine Familienanamnese, und im Entlassbrief gibt es auch einen Teil, dort werden die Medikamente beschrieben. Dann wissen wir also nur, es gibt einen Entlassbrief mit Anamnese und Medikamenten, aber die Medikamente sind nicht so strukturiert beschrieben, dass wir die direkt übernehmen können, sondern weiterhin einfach als Text. 

So, also Level 2 ist schon ein gutes Stück strukturierter, allerdings nicht Informationen wie Diagnosen oder Medikamente, sondern einfach nur, was ist es für eine Art Dokument. Diese Art von Dokument wird allerdings in der gleichen Art und Weise beschrieben, wie später in Level 3 dann auch einzelne Daten wie Diagnosen, Prozeduren. Und zwar wird dort einfach referenziert auf einen bestimmten Code in einem bestimmten Code-System. Also, so heißt zum Beispiel, die Anamnese kann codiert werden in dem Katalog LOINC mit dem Code 10164-2. Also LOINC-Code 10164-2 bedeutet Anamnese. Das lesen wir dann also und wissen, okay, wenn wir dieses CDA-Dokument eingelesen haben, da gibt es ein Dokument und da gibt es eine Anamnese. Und damit der Computer auch weiß, dass low ink LOINC ist, kann man diesen LOINC, also den Katalog selbst, auch nochmal verschlüsseln mit einer eigenen ID, das ist dann die OID. Die OID wird vergeben — weltweit von der WHO, in Deutschland vom DIMDI —, und ganz, ganz viele Objekte im Gesundheitswesen haben einfach so eine OID. So kann ein Hersteller von einem KIS eine OID haben, die HL7-Vereinigung von Deutschland hat eine eigene OID, aber auch Kataloge wie der ICD, wie der OPS, wie SNOMED CT haben eine eigene OID. Also man sagt erst LOINC, dann den Code, und dann weiß man, okay, dieser Abschnitt ist jetzt eine Anamnese, und dann kommt auch da wieder freitextlich der Text da drunter. Ist das so weit klar, war das halbwegs verständlich, Renato? — Also ich hab’s zumindest verstanden, ja. — Du hast das aber schon vorher verstanden. — Ja, aber ich hab mich dumm gestellt und hab’s trotzdem verstanden. 

Gut, dann kommen [wir] jetzt zum Level 3, das ist das, was man als richtiger Informatiker eigentlich glaubt, wie es sein sollte. Level 3 ist noch mal weiter ausgebaut, also all das, was Level 1 und 2 können, kann der auch, [und] zusätzlich kann der bei allen patientenbezogenen Daten auch verschlüsseln. Also wenn wir dort zum Beispiel eine ICD-Diagnose verschlüsseln wollen, und zwar so verschlüsseln wollen, dass man vom System A an System B diese CDA-Nachricht schickt und danach die Diagnose ganz normal dort eingetragen wird, als wenn man das selbst händisch gemacht hätte in diesem System B, dann kann man CDA Level 3 reinnehmen, und dann — wie ich das gerade schon mit der Anamnese erklärt hab — kann man das eben auch bei Diagnosen machen. Man sagt also einfach, es gibt zum Beispiel die A25.1, das ist der Code, und man sagt, das Code-System ist der ICD-10 in der German Modification von 2016. Dieser ICD-10 German Modification 2016 hat auch wieder so eine OID. Also man übermittelt einmal den Code und übermittelt, aus was für einem Katalog, und übermittelt auch noch mal freitextlich, damit der Mensch das lesen kann, dass diese A25.1 zum Beispiel allergisches Asthma ist. 

Und dann haben wir endlich das, was man eigentlich haben möchte. Man kann auf dem einen System einzelne [Daten] rausziehen, kann die exportieren in so eine XML-Datei, kann die im anderen System einspielen, und das hängt dann nicht irgendwie als PDF-Datei oder sowas rum, sondern man kann sagen, von diesen sechs Diagnosen, die da drin stehen, [suche] ich mir die vier hier aus und übertrage die ins neue System, und die stehen dann genau da an der Stelle, wo die Diagnosen stehen, wenn ich auch selbst dort eine Diagnose eintrage. Und das ist dann der richtig große Mehrwert eigentlich. 

Das ist auf jeden Fall [das, wo wir] hingehen [sollten]. Und das Spannende, was ich noch finde, ist — das ist ja eigentlich das Spannende. — Ja, das Spannende. — Dass CDA ja eigentlich ein Text-Dokument ist und dass man dann diesen Text annotieren kann. Also es bleibt auf jeden Fall menschenlesbar, auch wenn es dann für Maschinen ist. 

Genau, ja, gut, dann — also ich als Christian sage was zum eHealth-Gesetz, mach das. — Genau, also wir haben ja jetzt beim letzten Mal schon das Thema eHealth-Gesetz gehabt, und wir haben ja gesagt, dass eine zentrale Anwendung, die kommen soll, der elektronische Arztbrief ist. Und dass er ja jetzt schon in Teilen umgesetzt ist von [der] KV, aber das, denke ich, kann nicht der letzte Weg sein und auch nicht das, wo wir hinstreben. Weil wir brauchen einen offenen Standard, wir brauchen ein System, das nicht nur im ambulanten Sektor wirkt, sondern das für alles Mögliche gelten kann. Und da ist, denke ich, CDA als Übertragungsmedium das Mittel der Wahl und sollte auch kommen, und deswegen sollten noch alle etwas dafür tun, dass dieser Standard dann eingeführt wird. [Es] ist eben auch der weltweite Standard — warum sollen wir hier eine Sonderwurst sein in Deutschland, warum nutzt man nicht das, was in anderen Ländern schon erfolgreich funktioniert? 

Genau, und dann hat man noch den Vorteil — wir hatten ja auch in einem anderen Podcast schon mal das Thema, ich bin immer noch ganz begeistert, dass du mal iOS gelobt hast —, dass iOS mit seiner Health App auch schon CDA-Dokumente lesen kann. So was wären dann Abfallprodukte, die man dann noch mitnehmen könnte, wenn man sich in CDA und die ganze Sache reinarbeitet. 

CDA, HL7, eHealth-Gesetz, eArztbrief, CDA Brief, Header, Body, RTF Datei