Basic architecture
The configurable elements (tiers) used to develop the RDMS in OpenCampus are basically three types: forms (stored as nodes), Trees and input/output plugins (Fig. 1). A form or node contains fields that allow data entry in a given format (e.g. text field, drop down, reference selector). All forms are stored in the database without being tied to a specific software function or study.
The second tier is the Study Tree, which is a structural definition of containers and their relations to each other. Containers can hold forms, store conditions and actions. This allows to structure the data, build complex rule sets and develop software functions on an “if-this-then-that” basis. This basically describes an “electronic patient record” paired with software information that is needed to execute automatic actions, such as creating a medical report or e-mail notification.
The third tier provides Plug-Ins to use different formats for information input/output and actions. Plug-Ins can read and write the data stored in forms for conversion into email, PDF, mediastream, ECG data, Ultrasound data etc. or simple reformat information (replace text with image). Plug-Ins are also used to manage input/output of data to other systems in this way operating as middleware.
Every research project or clinical trial can always be mapped with the model shown in Fig. 1, using Forms (Nodes), Trees and the respective actions defined through plugins.
As all of these elements are fully configurable through a graphical user interface, no software development experience is needed to build a CTMS or a customized RDMS with the OAS from OpenCampus. The data cleaning process can already be implemented in the field verification and sanitization by checking that the inputted data has the right format and reasonable values with regard to the expected range values. For examples a field age can be allow only values ranging from 0 to 120 years and entered values higher 100 are highlighted in red font.
Interoperability
There are taxonomies that allows to classify content with terms that are gathered within vocabularies. Using taxonomies the field content can be stored not as a text, but as a reference linked to predefined values that can be downloaded open source. For examples ICD-10 codes for a specific diagnosis. Furthermore, field content can be operationalized to avoid typos and misclassification (field: “sex” only “men”/”women” are applicable as a preset).
Implementation in clinical research
A use case of OpenCampus will be presented in the following chapter, describing its implementation and customization in the Institute for Preventive Paediatrics at the Faculty of Sport- and Health Sciences of the Technical University of Munich.
At our Institution, several research studies are managed by numerous researchers. Figure 2 presents the structure of the access and permission management map for the various studies and researchers. The administrator responsible for the study has full access to the data and can view, edit, delete and export data sets.
Due to the complex structure of the studies in terms of the different levels of researchers and contributors, the importance of providing custom access and permission rights to individuals is paramount. For example, we involved a student research assistant (Study 1, Person C) whose access was restricted to solely creating new data, editing own data but not to delete or export the data. He was also just permitted to view his own published data.
These various levels of access and permissions control can be customized for each individual researcher across the various studies and institutes.
Multi-center
In a multi-center approach this concept works similar (Fig. 3). There is one single study administrator that assigns permissions to center coordinators. Center coordinators then independently distribute access and permissions to the data managers that are responsible for entering the data.
The granularity of the permission management concept allows each data manager to be able to access (within the group of accessible subjects of a center) data forms (nodes) like diagnostic data as ECG examination, Magnet resonance imaging (MRI) or ultrasound.
Data managers can now collect data in each study adding subjects and/or adding examinations. Using individual output “Views” they can display data they entered in various formats. Center coordinators can use output views to list and export data entered by any of his data managers. The study admin can use Views to list and export data, entered by any of the study centers within the respective study.
This concept ensures a convenient, location independent approach to collect study data, giving the peripheral units (study centers) full control to manage their own data pool and data base users. In addition, this feature offers all study centers the benefit of a supporting environment for patient care processes such as automated creation of clinical or statistical reports.
The multi center concept can be extended with various additional features such as node state levels or individual data processing guidelines that ensure that certain quality management actions are executed during data processing. This can be a mandatory review of data entered by a data manager: Each form filled in by a data manager is stored in ‘state 1’ after saving. Before the form is listed in the study data pool, it requires a review by a center coordinator who confirms the form by passing it into ‘state 2’.
Meta-analysis
One core element of the generic data storage approach in the OpenCampus OAS concept allows to connect nodes to each other. This link between nodes is called ‘entity reference’. Using entity references the data from multiple studies can be linked (merged), allowing meta-analysis to be executed just by creating a new output view.
For example we conducted a “Pregnancy Study” where we examined women throughout their pregnancy, monitoring glucose, BMI and blood pressure (Fig. 4). Later we conducted an “Outcome Study” in which the childrens’ birth weight, blood pressure and glucose were investigated. We then connected the nodes of the children with the nodes of the mothers and created an entity reference between the two studies that allowed us to create an output ‘View’ that displayed characteristics from the children along with characteristics of their mothers. No data import was necessary at this point.
Furthermore, links between examinations or other data nodes are possible, e.g. to cross evaluate all examinations for one patient that were performed during multiple studies.
Multi center data merge
It is also possible to merge contents from completely independent studies. As seen in Fig. 5, in a study “X” blood pressure was measured as a part of the research. Another study “Y” also contained blood pressure, measured in a comparable method and procedure. Thus it is easily possible to merge the data from those two, or even more studies or to compare it against each other.
Synergy between data collection and patient care operations
The RDMS provides condition based actions and outputs into formats such as email, PDF etc. which offers a seamless transition into patient care operations. At the same time, the system can provide us with medical reports, event planning, reminders and end user interaction. In clinical practice that allows examination data entered into OpenCampus, to be printed as a medical report and handed to the patient. Furthermore, a patient whose data were stored for medical purposes only can still give his consent online via OpenCampus, allowing the study center to use their data additionally for research purposes.
Exporting and importing configurations
Using the export function, study sets (the entire RDMS or even complete CTMS) can be exported or cloned as a ‘configuration’ for further studies. This includes all Forms, Trees and Actions performed by the CTMS. With this method, even complex clinical trial sets can be shared across institutions, reducing the initial configuration effort for an institution and providing a way to share best practice models and transfer knowledge in a very compact and efficient manner.
Data security
There are two major solutions. One possibility it the on-premise operation of the database with its physical location being within the hospital or patient care facility. The other possibility is a cloud based solution where signed patient consent is necessary. That complies also with the doctor-patient confidentiality. However the legal process is currently not fully reflected by the law.
