Mahnwesen
Für die Klinischen Studien der AG Studiendatenbanken 1
wurde ein Oracle-basiertes Mahnwesen entwickelt. Dieses kann
frei konfiguriert werden und ist deshalb flexibel auch bei neuen Studien einsetzbar. Während der
Spezifikationsphase für eine neue Studie wird ein Mahnplan für die Objekte (CRF, Blutproben, Röntgenbilder)
erstellt und dieser dann über das Admin-Tool des Mahnwesens konfiguriert. Komplexe, studienspezifische
Workflows können über eine API erweitert werden.
Motivation
Im Verlaufe von papierbasierten Studien wird die komplette Dokumentation eines Patienten an
das KKSL geschickt. Hier erfolgt dann die Eingabe der Daten in eine zentrale Datenbank. Die
Prüfärzte dokumentieren jedoch oft nicht zeitnah und müssen deshalb an noch ausstehende
Dokumentation erinnert werden. Bei Studien, die über mehrere Jahre hinweg Untersuchungen an
Patienten erfordern (Follow-Ups wegen Rezidiven z.B. bei Krebsstudien) ist es ebenfalls
notwendig, die Prüfärzte oder Patienten an in Kürze anstehende Untersuchungstermine zu
erinnern.
Zur Vermeidung von Doppelmahnungen und zu späten Erinnerungen muß für jeden Patienten eine
Liste mit den Zeitpunkten geführt werden, zu denen Dokumentation fällig ist. Meist werden
auch Blutproben oder Röntgenbilder erhoben, die ebenfalls zu mahnen sind. Dabei
ergibt sich ein weiteres Problem: man muß diese Mahnungen an verschiedene Adressen schicken
und meist reicht nicht nur ein Erinnerungsbrief aus.
Wird eine Patientin schwanger, so kann eine studienrelevante Röntgenuntersuchung nicht
durchgeführt werden. Dies bedeutet, daß für die Patientin diese Dokumentation nicht im KKSL
eintreffen wird. In einem solchen Fall darf das Röntgenbild auch nicht gemahnt werden, denn
es wurde nie erstellt.
An der Vielzahl der Probleme und Workflows sieht man, daß eine manuelle Pflege der zu erstellenden
Listen nicht oder nur sehr zeitaufwendig machbar ist. Ein datenbankbasiertes Werkzeug muß her.
Zielsetzung
Im KKSL entstanden mehrere unterschiedliche Versionen für das Problem Mahnwesen.
Für die NHL-Studien
wurde dies in der AG Studiendatenbanken 1 programmiert, wobei für jeden Sonderfall (abweichender Prüfplan für
einen Patienten) extra Code geschrieben wurde, der zu testen und zu pflegen ist.
Die neue Version sollte so wenig wie möglich Programmierung beinhalten und so generisch wie möglich
alle Studien-Workflows abbilden. Dazu fand eine intensive Zusammenarbeit mit dem Datenmanagement
statt, welche in der Version 1.0 umgesetzt wurde. Im Laufe der Zeit ergaben sich jedoch neue
Anforderungen und es zeigten sich Unzulänglichkeiten des Systems. Aus diesem Grund wurde eine
weitere Version entwickelt.
Das Grundkonzept ist simpel:
Über eine Bogenregistratur wird jedes studienrelevante Dokument eines Patienten registriert. Damit
hat man einen Überblick, welche Dokumente vorhanden sind. Ein Prüfplan beschreibt, welche Dokumente
wann (in Bezug auf den Einschluß des Patienten) im KKSL vorzulegen sind. Dabei werden noch Karenzzeiten
eingerechnet, die bei einer postalischen Übermittlung benötigt werden.
Es erfolgt nun der Abgleich beider Listen, man erhält die noch ausstehende Dokumentation. Ein
Stichtag (z.B. das aktuelle Datum) filtert zu mahnende Dokumente (vor dem Tag) oder zukünftig
zu sendende Dokumente (nach dem Stichtag).
Dokumente können mehrfach angemahnt werden, wurde eine Mahnung durchgeführt, so ist eine weitere
Mahnung erst nach dem Verstreichen einer bestimmten Karenzzeit durchzuführen. Auch dies wird
vom Mahnwesen unterstützt.
Desweiteren bietet das Mahnwesen Funktionalitäten zum automatischen Streichen von Dokumenten bei
Patienten, die die Studie vorzeitig verlassen, ebenso ein Anpassen des Prüfplanes für einen oder
alle Patienten, wenn sich allgemeine Verzögerungen im Studienablauf ergeben.
Alle Informationen sind in der Datenbank enthalten, ein Report, basierend auf Oracle Reports, visualisiert
den Dokumentationsstand für jeden Patienten. Serienbriefe können an die Prüfärzte verschickt werden,
um die ausstehende Dokumentation nachzufragen.
Versionen
Das Projekt Mahnwesen begann im Mai 2002 mit der Erstellung eines Reports, welcher die vorhandene und
ausstehende Dokumentation der Patienten in der Sirus-Tibia-Studie auflistete. Durch diesen Report wurde der
Mahnworkflow dahingehend erleichtert, daß an einer zentralen Stelle eine Übersicht über die gesamte
Studiendokumentation vorhanden war.
Die Version 1.x (ab Oktober 2002) wird bereits konfiguriert, hier konnten patienten- und studienspezifische Änderungen
am Prüfplan definiert werden, so daß keine unnötigen Mahnungen für nicht mehr beizubringende Dokumentation
generiert wird. Auch ist es möglich, Anhänge an Serienbriefe zu drucken. Dies vereinfachte die anfallenden
Arbeiten im Datenmanagement weiter.
Die aktuelle Version 2.07 (ab Dezember 2004) wurde intern neu konzipiert (Realtime-Änderungen anstatt
Materialized Views) und bietet einen erweiterten Überblick über die Dokumentation. Erstmals werden mehrere
Mahnziele unterschieden (z.B. Labor, Klinik, Hausarzt) und nicht mehr beizubringende Dokumentation
visualisiert. Das Mahnwesen wurde abgegrenzt vom Rest der Studiendatenbank, damit es unverändert in
verschiedene Studien übernommen werden kann. Dies verringert den Wartungsaufwand bei einer Fehlersuche.
Stand des Projektes
Das Datenbank-Modul kann über SQL-Scripte in jede neue Studien-Datenbank eingepflegt werden.
Für die Konfiguration ist ein Admin-Tool verfügbar. Derzeit eingesetzt wird das Mahnwesen in der Version 1.14
in den Studien PET und Hepatitis, Gest und HWS, in der Version 2.07 ist es in Tibia, MInT und Kinder-HD integriert.
Aktuell läuft die Integration in eRT-Studien der AG Studiendatenbanken 2, hier soll das Mahnwesen zunächst im Kompetenznetz
Herzinsuffizienz eingesetzt werden.
Noch ausstehend ist die Dokumention der aktuelle Version und die Programmierung von Skripten zur Integration in
bereits bestehende Datenbanken. Ebenfalls fehlt noch die Möglichkeit von Klinikswechseln durch die Patienten und
die automatische Umleitung von Anschreiben bzw. das Mahnen der ausstehenden Dokumentation bei der richtigen
Klinik nach einem solchen Wechsel.
Zurück zur Vorstellung der AG Studiendatenbanken 2
|