ArchivDeutsches Ärzteblatt12/2009Qualitätssicherung: Problematisch
Als E-Mail versenden...
Auf facebook teilen...
Twittern...
Drucken...
LNSLNS
Die Ausgangslage mit der Problematik der Mehrfachdokumentation ist treffend beschrieben, und es ist sicher verdienstvoll, Lösungen für diese Problematik zu suchen, indem die genannten unterschiedlichen Dokumentationen abgeglichen und synoptisch dargestellt werden. Der vorgestellte Vorschlag greift aber leider zu kurz . . . Das in dem Artikel dargestellte Kommunikationsszenario beschreibt offensichtlich nur den Gesamtexport onkologischer Information aus einem Quellsystem „Krankenhaus“ in mehrere Zielsysteme. Die Behandlung und somit die Daten sind aber in der Realität häufig fragmentiert und über mehrere Behandler im stationären und ambulanten Bereich verteilt. Zeitliche Aspekte lang dauernder Behandlungen und Nachbeobachtungen müssen damit zwangsläufig außer Acht gelassen werden – onkologische Dokumentationen sind im Grunde immer nur komplett in Bezug auf einen bestimmten Zeitpunkt. Sie enden im Extremfall erst mit dem Tod des Patienten, sei es am, mit oder ohne manifesten Tumor. Daraus folgt, dass solche XML-Dokumente entweder mit nicht selbst erhobenen Daten ergänzt werden müssen, um der erforderlichen Vollständigkeit zu genügen oder fragmentarisch bleiben müssen und damit eventuell durch Prüfraster fallen. Das gilt zu einem gewissen Grad für jeden Behandler eines bestimmten Falls aus unterschiedlichen Einrichtungen, und es führt wiederum zu Mehrfachdokumentationen gleicher Sachverhalte, die eigentlich vermieden werden sollten. Die Dokumente unterschiedlicher Einrichtungen können in dem beschriebenen anonymen Konstrukt mangels Record Linkage gerade nicht gegenseitig ergänzt werden. Was soll in dem Szenario passieren, wenn die Informationen zu einem Patienten z. B. mit einem Rezidiv ergänzt werden? Dann wieder ein vollständiges XML-Dokument zu produzieren, ist sicher kein Problem und, wenn man es unter dem Aspekt von Benchmarking oder Auditierung durch Zertifizierer betrachtet, auch sinnvoll. Aber bereits die BQS dürfte Probleme haben, denn wie sollen Primär- und Rezidivoperationen unterschiedlicher Behandler unterschieden werden? Auch für klinische Register wäre es äußerst mühsam, jeweils vollständige Dokumente mit dem eigenen Informationsstand zum Fall abzugleichen. Darüber hinaus können die erwähnten Schemaprüfungen nur einen gewissen Grad formaler Korrektheit garantieren. Inhaltliche Widerspruchsfreiheit muss durch gesonderte Prüfroutinen gewährleistet werden. Diese dürften dann aber in der Regel nicht XML-basiert ablaufen. Richtigkeit kann, wie behauptet, überhaupt nicht geprüft werden, denn auch plausible Daten können falsch sein. Es ist auch fraglich, warum noch ein Dienstleister als quasi Vermittler eingeschaltet werden soll. Wenn alles automatisch ablaufen kann, reicht ein Programm, das auf einem Rechner des Krankenhauses läuft. Das ist datenschutzmäßig eine erheblich sauberere Lösung. Solch ein Programm könnte auch die Verteilung der Daten auf die unterschiedlichen Empfänger übernehmen. Im Grunde muss an die Stelle des beschriebenen Dienstleisters das klinische Krebsregister treten. Regionale klinische Krebsregister sind in der Lage, Informationen unterschiedlicher Behandler zu einem Fall zusammenzuführen und daraus einen vollständigen „Datensatz“ zu produzieren. Dabei gilt es unter anderem, gleichartige, aber untereinander abweichende Informationen zu einem Teilgeschehen aus unterschiedlichen Quellen im Sinne eines „Best-of“ zusammenzufassen . . . Das systematische Durchforsten von Prozessen in solchen Originalsystemen könnte zur Definition einer Reihe von onkologischen Nachrichten führen, die, an ein Register gemeldet und dort verknüpft, insgesamt eine umfassende onkologische Registerakte ergeben, die inhaltlich genau das Gleiche abbildet, wie im Beitrag dargestellt. XML ist selbstverständlich für solche Übermittlungen ein geeigneter Kandidat, weil eine Reihe nützlicher Werkzeuge zur Darstellung und Weiterverarbeitung existiert. Die Definition entsprechender Schemata steht jedoch erst am Ende solcher Entwicklungen und bedarf der Mitwirkung und Akzeptanz durch die Softwareindustrie . . .
Für die Verfasser:
Dr. med. Udo Altmann, Sprecherteam des Forums Klinischer Krebsregister, Institut für Medizinische
Informatik, Heinrich-Buff-Ring 44, 35392 Gießen
Anzeige

Leserkommentare

E-Mail
Passwort

Registrieren

Um Artikel, Nachrichten oder Blogs kommentieren zu können, müssen Sie registriert sein. Sind sie bereits für den Newsletter oder den Stellenmarkt registriert, können Sie sich hier direkt anmelden.

Fachgebiet

Zum Artikel

Anzeige

Alle Leserbriefe zum Thema