gms | German Medical Science

Einführung: In dem Projekt „Verbesserung der Versorgungsforschung in der Akutmedizin in Deutschland durch den Aufbau eines Nationalen Notaufnahmeregisters“ (AKTIN) [1] werden die Daten in den Notaufnahmen standardisiert erfasst und in einem lokalen Data Warehouse (DWH) System i2b2 (Informatics for Integrating Biology & the Bedside) [2] gespeichert. Das Ziel des Projektes ist, die verteilt in den Kliniken liegenden Daten je nach Anforderung zusammenzuführen und somit Einrichtungsübergreifende Datenanalysen zu ermöglichen. Für die Implementierung des Verfahrens war es notwendig, den Prozess der Datenanfrage und Freigabe formal zu beschreiben.

Stand der Technik: Ein Ansatz zur Durchführung von Abfragen auf mehreren i2b2 Instanzen ist die SHRINE-Software [3]. Diese setzt auf eine automatische Ausführung ohne Interaktion oder Kontrolle durch die lokalen Dateneigner. Das Kozept von AKTIN sieht jedoch vor, dass die Datenhoheit bei den Notaufnahmen verbleibt und diese jeweils den einzelnen Anfragen für Berichte und Forschungsvorhaben zustimmen müssen bzw. können. Eine ähnliche Vorgehensweise findet sich im Brückenkopfmodell [4] im Deutschen Konsortium für Translationale Krebsforschung (DKTK). In dem Brückenkopfmodell werden die Anfragen verteilt, dies umfasst jedoch keine Freigabe oder Übermittlung der Abfrageergebnisse. Da vorhandene Software unsere Anforderungen nicht erfüllt, wurde ein neues Konzept entwickelt.

Konzept: Die Anfragen enthalten die eigentliche Abfragesyntax (z.B. SQL) und einige Metadaten, wie Anfrageersteller und Beschreibung. Eine Anfrage kann in der Notaufnahme verschiedene Zustände annehmen: An unterschiedlichen Stellen soll die Möglichkeit bestehen, die Anfrage freizugeben oder abzuweisen. Es soll jedoch auch möglich sein, z.B. periodische Anfragen ohne weitere manuelles Interaktion automatisiert zu erlauben.

Implementierung: Um die Zustandsänderungen der zentralen Anfragen in den lokalen DWHs darzustellen, wurde ein Ablaufdiagramm erstellt. In diesem sind die Zustände (in spitzen Klammern notiert) der Anfragen in der zeitlichen Reihenfolge dargestellt. Nach der Übertragung der neuen Anfrage new wird der lokale Benutzer benachrichtigt. Sobald der Benutzer die Anfrage gesehen hat, wird der Zustand auf seen gesetzt und es wird auf Benutzerfreigabe gewartet. Die Anfrage kann abgelehnt rejected oder angenommen queued werden, wobei diese in die Warteschleife aufgenommen und dann ausgeführt wird running. Sollte Fehler bei der Ausführung der Abfragesyntax auftreten, wird der Zustand auf failed gesetzt. Nach der erfolgreichen Auswertung completed wird erneut auf Benutzerfreigabe gewartet, wobei der Benutzer das Freigeben der Ergebnisse ablehnen kann rejected. Bei Freigabe werden die Ergebnisse an den zentralen Aggregator gesendet sending, wobei erneut failed auftreten kann, oder bei Erfolg dann submitted.

Bei jeder neuen Anfrage kann bei der initialen Freigabe festgelegt werden, dass die Ergebnisse automatisch, ohne weitere Freigabe, übertragen werden. Bei einer periodischen Anfrage kann außerdem festgelegt werden, dass alle weiteren Anfragen mit gleicher Abfragesyntax automatisch ausgeführt werden. Diese Ausnahmen gelten jedoch nur für die jeweilige Anfrage bzw. Folgeanfrage derselben Reihe. Bei Änderungen an der Anfragereihe müssen die Freigaben erneut erteilt werden.

Lessons Learned: Bei verteilten Abfragen ist die asynchrone Übermittlung und Freigabe zu berücksichten. Der Freigabeprozess ist in den Projektkliniken unterschiedlich geregelt. Teilweise erfolgt die Freigabe durch die Leiter der Notaufnahme, teilweise werden Klinikleitung und Datenschutzbeauftragte einbezogen. Das resultierende Ablaufdiagramm reflektiert die verschiedenen möglichen Zustände, inklusive Ablehnung oder Fehler während der Ausführung oder Übermittlung.

Das Projekt wird vom BMBF finanziert (Förderkennzeichen 01KX1319B)

Die Autoren geben an, dass kein Interessenkonflikt besteht.

Die Autoren geben an, dass kein Ethikvotum erforderlich ist.