gms | German Medical Science

Einleitung und Fragestellung: Die Erstellung von Informationssystemen für klinische Forschung auf der Grundlage von Software zur elektronischen Datenerfassung (EDC, engl. electronic data capture) für klinische Prüfungen ist einerseits aufwendig, andererseits ist bei vielen Projekten mehr Flexibilität erforderlich als derartig spezialisierte Software ermöglicht. Das liegt nicht zuletzt an einer relativ starr vorgegebenen Datenstruktur, wobei der Heterogenität der klinischen Daten durch EAV (Entry-Attribute-Value)-Schemata Rechnung getragen wird, einem Ansatz, der zunächst einmal jede Datentypisierung auf der Ebene des Datenbanksystems außer Kraft setzt. Weiterhin werden Metadaten nur in begrenztem Umfang nutzbar gemacht. Dadurch werden intelligente Lösungen, die gleichzeitig leicht handhabbar sind, erschwert. Wir stellen hier einen Gegenentwurf vor, der Nutzdaten und Metadaten in einem gemeinsamen relationalen Schema integriert, vielfältige Datentypen ermöglicht und generische, Datentyp-abhängige (oder auch objektorientiert) Verarbeitung begünstigt.

Material und Methoden: Der beschriebene Entwurf ist als EDC-Baustein für inzwischen etliche klinische Forschungsprojekte realisiert. Er besteht aus einem generisch konfigurierbaren Web-Formulargenerator „dbform“ und einem Formularcompiler, der die nötigen Konfigurationsdaten für den Formulargenerator aus einem formalisierten Datenverzeichnis erzeugt. Das System wurde erstmals in [1] beschrieben und seither in vielfältiger Hinsicht verbessert. Der Formgenerator läuft auf einer Plattform mit Webserver und relationales Datenbanksystem. Unsere derzeitige Wahl ist Linux, Apache [2] und PostgreSQL [3], andere Umgebungen sind möglich. Die vorherrschende Implementierungssprache ist Perl [4].

Es handelt sich um ein modulares System das mit verschiedenen Datenbank-Managementsystemen (DBMS) betrieben werden kann. Es stellt u.a. ein Application Programming Interface (API) bereit, das projektspezifische Erweiterungen ermöglicht.

Ergebnisse: Kern des Ansatzes ist, dass der Datenkörper alle relevanten Informationen, also Nutzdaten und Metadaten, vereinigt. Dabei sind die Metadaten ebenfalls relational hinterlegt und als formale Sprache hinreichend mächtig, um sich selbst syntaktisch zu beschreiben. Dadurch wird erreicht, dass selbst bestimmte Minimalrelationen (z.B., um Patient, Studienzentrum, Systembenutzer, Rollen, etc. darzustellen), die vorhanden sein müssen, dennoch hinsichtlich ihrer Attribute für jedes Projekt weitgehend frei definiert werden können.

Der Teil der Nutzdaten, der den sog. Case Report Forms entspricht, ist ebenfalls in Relationen hinterlegt, die etliche gemeinsame Attribute – zusammen als „Kontext“ bezeichnet – tragen. Auch der Kontext ist in einem gewissen Umfang flexibel gestaltbar. Textuelle Metadaten als auch Nutzdaten können mehrsprachig sein. So können nicht nur Formulare mehrsprachig gestaltet werden, es können auch mehrsprachige Nutzdaten verarbeitet, z.B. nach der Erfassung von Übersetzern in eine gemeinsame Sprache übersetzt werden.

Das zweite wesentliche Entwurfsprinzip ist die konsequente Typisierung von Daten, wobei zusätzlich zu den Datentypen des DBMS weitere Typen benötigt werden und auch vorhanden sind. Ein oft eingesetztes Beispiel unter vielen sind partielle Datumsangaben.

Diskussion: Erst reichhaltige Metadaten ermöglichen effiziente generische Funktionalitäten. Letztlich können dazu sogar die Metadaten ergänzt oder geändert werden, was die Vielseitigkeit generischer Verarbeitungsmöglichkeiten noch einmal deutlich ausweitet. Diese Generizität ermöglicht den Verzicht auf EAV-Schemata trotz Datenheterogenität, was nicht nur in Bezug auf Performanz von Vorteil ist. Auch für das Design von verteilten Informationssystemen [5], insbesondere hinsichtlich einer effektiven und inhaltlich sinnvollen Interoperabilität, sind generische Funktionalitäten von zentraler Bedeutung.