Author affiliations:

Richard E. Gliklich, M.D.^a
Daniel Levy, M.S.^a
Jannette Karl, M.B.A., P.M.P.^a
Michelle B Leavy, M.P.H.^a
Thomas Taylor^a
Daniel M. Campion, M.B.A.^a

^aOutcome DEcIDE Center, Cambridge, MA

Structured Abstract

Objectives. The purpose of this project is to engage stakeholders in the design and development of the Registry of Patient Registries (RoPR) database system that is compatible with ClinicalTrials.gov and meets the following objectives: (1) provides a searchable database of patient registries in the United States; (2) facilitates the use of common data fields and definitions in similar health conditions; (3) provides a public repository of searchable summary results; (4) offers a search tool to locate existing data that researchers can request for use in new studies; and (5) serves as a recruitment tool for researchers and patients interested in participating in patient registries. This document describes the approach used to design the RoPR and provides an overview of the system design.

Data Sources. Not applicable.

Methods. Stakeholders participated in Web conferences and in-person meetings to discuss use cases, data elements relevant to patient registries, search tools, and policies and procedures.

Results. Stakeholder feedback shaped the RoPR requirements and design. Once the complete set of requirements was compiled, options were examined regarding the practical aspects of implementation, as well as the extent to which the RoPR should be integrated with ClinicalTrials.gov. While there was some debate among stakeholders as to whether or not the RoPR should be a standalone system, there was widely recognized value in being integrated with ClinicalTrials.gov, and it was determined that the RoPR will be integrated with ClinicalTrials.gov. Multiple design options were considered, and a hybrid model was selected. In the hybrid model, the ClinicalTrials.gov system will undergo some changes to introduce the "Patient Registry" Study Type and add six of the registry data elements for the ClinicalTrials.gov patient registry record. The RoPR record will include additional patient registry data elements identified by the stakeholders. Users will easily navigate between ClinicalTrials.gov and the RoPR in order to register the RoPR record or search and view results for these data elements.

Conclusions. Stakeholder feedback was essential for developing the RoPR system. The hybrid model for the RoPR was selected because it best supports the stated needs of stakeholders while balancing project constraints. This solution leverages the existing ClinicalTrials.gov registration and search portals to establish a common portal entry point for accessing both the registration and search functions of the RoPR.

Overview

The primary purpose of the Registry of Patient Registries (RoPR) is to provide a searchable central listing of registries. As envisioned, the RoPR will contain summary information for each listed patient registry that would enable a user of the RoPR to understand a registry’s purpose, design, clinical focus, goals, targeted outcomes (if applicable), and progress towards its goals. The RoPR will include descriptive information on the data being collected, particularly with respect to standardized elements and outcomes. This descriptive information will describe the registry as a whole, and will not include patient level information. In addition, similar to the goal of ClinicalTrials.gov, a searchable listing of patient registries will improve transparency and access to information about registries. While the RoPR is designed to meet the needs of US stakeholders, registries not located within the United States may also register in the RoPR.

Goals

The primary goal of this project is to engage stakeholders in the design and development of the RoPR database system that is compatible with ClinicalTrials.gov and meets the following objectives:

• Provides a searchable database of patient registries in the United States (to promote collaboration, reduce redundancy, and improve transparency);
• Facilitates the use of common data fields and definitions in similar health conditions (to improve opportunities for sharing, comparing, and linkage);
• Provides a public repository of searchable summary results (including results from registries that have not yet been published in the peer-reviewed literature);
• Offers a search tool to locate existing data that researchers can request for use in new studies; and
• Serves as a recruitment tool for researchers and patients interested in participating in patient registries.

Stakeholder Input

The first phase of the RoPR project involved extensive stakeholder engagement, including in-person meetings and Webinars. Over 300 stakeholders from a variety of stakeholder groups were engaged to discuss use cases, data elements relevant to patient registries, search, policies and procedures, and the resulting specific RoPR requirements.

The use cases presented and supported by stakeholders involved the following primary roles:

• Registry Holders, who would list information regarding their registry.
• Registry Seekers, who would search and find information regarding registries which have been listed.
• Registry Reviewers, who would ensure the listed registry information was accurate, consistent, and of high quality to be useful for Registry Seekers.
• Registry Administrators, who would handle the maintenance and operation of the RoPR, and support the needs of the preceding roles.

Stakeholders provided valuable input regarding how they would like to search for the data, what type of feedback they wished to see as they progressed through the process of listing their data, and what data elements they wished to see when searching for listed registries. The following summarizes the data element sections identified by stakeholders for describing a RoPR registry record:

1. Registry Description—identification and description information.
2. Registry Classification and Purpose—information about the type of registry and its intended purpose.
3. Sponsor and Conditions of Access—information about the sponsor, collaborators, conditions of access, and related contact information.
4. Registry Design—information and references to the Registry Design, including the protocol definition.
5. Eligibility—eligibility criteria for patient enrollment in the registry.
6. Conditions, Exposures, and Keywords—the condition(s) or exposure(s) of focus of the registry, and related keywords.
7. Common Data Element Groups by Condition—this section contains lists of data element standards, scales, instruments, and measures utilized by the registry.
8. Status—registry participation status, and registry start and stop dates.
9. Quality Procedures—information about the quality procedures being conducted for the registry.
10. Progress Report—information associated with the registry including growth of the registry and any relevant references to available progress reports.
11. Related Information—links to related publications, citations, and other relevant information.

Once the complete set of actors, use cases, requirements, and data elements was compiled, options were examined regarding the practical aspects of implementation, as well as the extent to which the RoPR should be integrated with ClinicalTrials.gov. These options were discussed among stakeholders, the Agency for Healthcare Research and Quality (AHRQ), and the National Library of Medicine’s ClinicalTrials.gov team members. While there was some debate amongst stakeholders as to whether or not the RoPR should be a standalone system, there was widely recognized value in being integrated with ClinicalTrials.gov. The primary benefits of integrating with ClinicalTrials.gov would include the international recognition of ClinicalTrials.gov, awareness of its use, and policies and procedures encouraging or mandating that use. It was clear that stakeholders desire a single point of access to register and search for a variety of study types (clinical trials, observational studies, and patient registries) and wish to minimize the burden necessary to register a study and maximize the ease with which search and identification can be achieved.

Project Constraints

A number of factors must be taken into account when considering a design and implementation path forward for the RoPR. The following project constraints were discussed as part of these considerations:

• Stakeholder input—as this project focuses on a user-centered design approach, the goals of the project are to incorporate as much stakeholder input as possible into the design of the RoPR.
• Integration with ClinicalTrials.gov—a stated objective of the project is to consider a solution that leverages ClinicalTrials.gov. The awareness of ClinicalTrials.gov and the mandates for its use present compelling arguments for using ClinicalTrials.gov as a platform for the RoPR. ClinicalTrials.gov also already exists, and can be modified to accommodate patient registry records. However, the existing ClinicalTrials.gov system and infrastructure impose specific technical constraints that make developing additional features with a RoPR-specific database necessary to more fully support stakeholder requirements. A RoPR system without any relationship to ClinicalTrials.gov could be built to include all of the stakeholder-identified requirements and desired features, but would require considerable resources to build and maintain, and would not be able to immediately address the mandates for registration on ClinicalTrials.gov.
• Funding and ongoing costs—the RoPR project is currently funded for 3 years. At the end of the three years, continued operation of the RoPR would require additional funding. The design and implementation of the RoPR should consider how best to minimize ongoing maintenance and support costs, and consider technology selections that would allow for a smooth transition to a future owner.

Architectural Design

In consideration of the goals and constraints described above, a number of design models were presented. These models range from two separate standalone systems (ClinicalTrials.gov and the RoPR) to one integrated system satisfying only limited stakeholder requirements, with a range of integrated or hybrid models in between.

The model that best achieves the project goals and balances the set of project constraints is a hybrid design model. In this hybrid model, the solution would include changes to be implemented within ClinicalTrials.gov and additional external development as part of the RoPR effort, which will include a separate Web site and database for patient registry specific data elements which are not supported on ClinicalTrials.gov. These RoPR efforts would allow for additional stakeholder requirements to be supported and accessible via links from ClinicalTrials.gov.

ClinicalTrials.gov will be modified to accommodate patient registry-specific records as follows: a new "Study Type" called "Patient Registry" will be introduced (to be distinguished from the existing definition of the ‘Observational Study’ Study Type); six (6) new patient registry-specific data elements will be added to the new Patient Registry "Design" section; and a number of links will be added to ClinicalTrials.gov to support the workflow for registering, viewing, and searching RoPR records. These workflows are displayed in Figure 1.

Figure 1. RoPR integration with ClinicalTrials.gov

CTgov = ClinicalTrials.gov; RoPR = Registry of Patient Registries; PRS = ClinicalTrials.gov Protocol Registration System

There are three distinct integration pathways illustrated in Figure 1:

1. Link to RoPR Web site for data entry—a hyperlink will be provided from within the ClinicalTrials.gov Protocol Registration System (PRS) that will allow data providers to access the RoPR registration system. The additional Registry data elements will be requested only if the "Patient Registry" Study Type has been designated. The PRS will act as a common registration portal for different types of records, including clinical trials, observational studies, and patient registries.
2. Link to the RoPR record—a hyperlink will be provided from within ClinicalTrials.gov that will link the ClinicalTrials.gov patient registry record (NCT#) with the RoPR registry record (RoPR#) for "Patient Registry" Study Types that have entered a RoPR record. This will allow a user to view detailed registry results and easily navigate from the ClinicalTrials.gov patient registry record to the RoPR record. The RoPR record will also be accessible to the general public on the RoPR Web site.
3. Link to RoPR search portal—a hyperlink will be provided from within ClinicalTrials.gov Advanced Search that will link the user with the RoPR search portal. The RoPR search portal will allow a user to search on RoPR Record data elements. The RoPR search portal may also be accessed independently or made available from other Web sites such as that of AHRQ.

Summary

The hybrid design model described above was chosen because it best supports the stated needs of stakeholders while balancing project constraints. The ClinicalTrials.gov system will undergo some changes to introduce the ‘Patient Registry’ Study Type and add six (6) of the registry data elements for the ClinicalTrials.gov patient registry record. The RoPR record will include additional patient registry data elements identified by the stakeholders. Users will easily navigate between ClinicalTrials.gov and the RoPR in order to register the RoPR record or search and view results for these data elements. This solution leverages the existing ClinicalTrials.gov registration and search portals to establish a common portal entry point for accessing both the registration and search functions of the RoPR.