gms | German Medical Science

Introduction: Clinical studies require to document large sets of data that is collected within electronic data capture systems (EDC), but often after manual documentation. However, large amounts of study data are frequently available as data documented by routine care within the hospital information system (HIS). Thus, it would “only” require a data transformation and transferal into the EDC system [1]. But what are the transformation steps necessary to utilize usual data from HIS (single and tabular data elements) in all its detail to fill EDC system forms? This work categorizes the transformation experiences from the Acute Heart Failure Registry (AHFR).

Methods: A clinical data warehouse (DWH) has been developed and deployed at the University Hospital of Würzburg, providing pseudonymized access to data of our HIS. Since the data transformations for the AHFR not only require simple transformations but also very specific aggregations, a comprehensive R interface was developed and described previously [2].

Results: The setup was used to import AHFR study patients (n=800) into the EDC system. During the development of the transfer pipeline, we had to solve several transformation problems, which we grouped into basic transformation patterns (i.e., A to C).

A. Single data elements in and out. The simplest example is the direct adoption of single data elements from a base system without the need for any further transformation of the data itself. Such data elements typically have no direct relation to other data elements except that they belong to the same patient and/or patient case.

B. Multiple related data elements in and single data elements out. More complexity exists if the input data elements are linked to each other. This might be the case if a data element has multiple attributes and if this element (and its attributes) occurs multiple times during a hospitalization or study event (e.g. a single day).

C. Multiple related data elements in and out. Most complex transformations arose from the need to transform multiple input data elements that are linked to each other to multiple output data elements that are linked to each other, which might include additionally custom calculations in-between. Such data elements typically occur multiple times during a single hospital visit.

Discussion: This work exemplifies patterns of transformations and aggregations required to transfer data between a HIS and an EDC system in the context of a large clinical study. A very basic requirement a DWH needs to fulfill in order to handle more complex and related data and to prefill an EDC system as described above, is the linkage between multiple data elements on the level of documents. I2B2 for examples supports a similar functionality with its “modifiers” concept [3]. A key question in any DWH setting is the decision where to aggregate the data. This could be done between the HIS and DWH, meaning that the person using the DWH already has the final variables. This would also reduce the complexity of DWH query systems. However, even with the simplest data, conflicting requirements may occur with different studies.

Die Autoren geben an, dass kein Interessenkonflikt besteht.

Die Autoren geben an, dass kein Ethikvotum erforderlich ist.