gms | German Medical Science

Introduction and question: Patient Registries in medical research, clinical epidemiology, and quality management require a thoroughly and accurate planning and construction of a suitable IT infrastructure. Detailed descriptions how to plan and run the registry based on legal and ethical aspects as well as strategies of patient recruitment [1] need to be considered. Checklists for Registries for Health Services Research (as for example [2]) try to support the planning process and define common points like the registry protocol describing the motivation and research focus of the registry.

Besides the conceptual framework, the quality of the software systems used is important to run patient registries successfully. Commercial as well as open-source software systems are available. Many institutions develop in-house solutions which fit their needs and allow flexible changes.

Guidance is needed to support assessment and selection of an existing, or to plan the development of a new registry software system.

Therefore, we developed CIPROS (a checklist with items for a patient registry software system) and present it in the style of “The Revised CONSORT Statement for Reporting Randomized Trials: Explanation and Elaboration” [3]. The checklist is derived from own experiences in this field [4] and a systematic review of the literature.

Several initiatives aim to improve software systems and semantic infrastructure to support clinical research and interoperability: The caBIG® [5] program certified existing software systems, according special criteria. The recent National Cancer Informatics Program [6] aims to support interoperability in Medical Research in providing open-source code for biomedical informatics software applications and in providing semantic infrastructures. A National Metadata Repository for Clinical Studies and Registries is provided by TMF e.V. [7]. There is also an ongoing TMF project to define common requirements for cohorts and registry-IT.

Material and methods: We identified papers with patient registry software system descriptions by searching in Pubmed: “(registry or registries) AND (eCRF or EDC or CDMS or CTMS or web) AND (software or open-source or open source or Java)”. This search delivered 132 results. We classified these papers by reading title and the abstract. Out of these 132 results we analyzed 40 papers containing a system description or at least a short system description.

We searched these 40 papers for relevant software specific features. Features which we judged by our own experiences inapplicable or inappropriate were skipped or modified.

Results: Based on these software specific features and inspired by the caBIG^® [5] criteria we created a checklist with 67 items organized in ten logical system components, aspects or design steps. Like [3] we explained our Items with good Examples from the literature. Because of the limited space in an abstract we present without details just the ten components and the 67 items. For one item we also present the full Example and the Explanation.

1.

Architecture: System architecture, Platform independence

2.

Development and Training: Design model, framework-based design, questionnaire builder, usability testing, performance testing, user manual, user training, user feedback

3.

Interfaces: End-user Interfaces: Web-Interface, Compatibility, email-alerts, messaging interface, online discussion forum, mobile interface, patient interface; Programming interface: Third-party access, API for inserting data, API for retrieving data, data update mechanism; Interfaces to other systems: Interface to CIS, Integration of biological data, extensibility is possible

4.

Interoperability: Open Source; Semantics and Standardization: CRFs, Metadata, Vocabularies, XML Schema

5.

Internationality: Multilingualism

6.

Data management and data quality: Pseudonymous patient identifier, CRF is divided in parts, Customizable CRF parts, minimal and extended dataset, all data types are supported, special data types are possible, multiple choice is used, no predefined selection, data validation components, data query tool, interface for manual data check, manual data queries, data query flags, plausibility flags, insertion of unplanned visits

7.

Data Analysis: Query builder for researches, report generation, download of datasets graphical presentation of results, risk analysis

8.

Security aspects: Authorized users, role-based access, encrypted data transfer, encrypted data storage, audit trail, master-slave replication, backup-management, firewall, server room

9.

General Features: Costs are an argument, several projects simultaneously, Update mechanism, source documentation in pdf

10.

Organizational: Compliance with regulations, Informed Consent, Rights on the data, data protection guidelines

Item 3.1 The patient registry software system has a web-interface.

Example: The CERTAIN web application … supports therefore not only the data entry, presentation, visualization, and export, but also the automatic and manual data validation. These functionalities are active at any time and location, requiring only a common web browser and internet access [8].

Explanation: We recommend a web-interface for patient registry software systems. Web-based data entry is a very comfortable and a state of the art way to collect patient data for multi-center registries. All data are immediately available in the database. The data from all centers are collected in the same way, no data-integration with the data from different centers is necessary. No additional software must be installed at the client side. When a software update is necessary, it must only be installed at the server, the clients get a new version when they log in next time.

The 40 references used to build the list, and the complete Table with Checklist Items and Description is available from the corresponding author (lindoerf@ibe.med.uni-muenchen.de).

Discussion: The CIPROS checklist comprises 67 items organized in 10 components. The checklist items focus on reporting how a patient registry software system is designed, implemented, and run. Considered an evolving document, the CIPROS checklist has to be subject to periodic changes as new construction principles evolve. The aim of the CIPROS checklist is to provide study coordinators, developers and decision makers with an instrument to evaluate existing systems. It allows checking item by item, if their registry project complies with these features. It also helps in choosing an existing system or in developing an own solution. Like the CONSORT Statement [3], which will improve the reporting of clinical trials, our checklist can help, when publishing a paper with a patient registry software system description, to describe the system comprehensively. Our checklist CIPROS can help to create standards in registry-based medical research, for which is also a need.