Steps in the R-RCT process

About the steps in the R-RCT process

The different steps in the R-RCT process are based on meetings between different roles involved in the planning and development of the study, the technical solution/study application as well as consideration of regulatory requirements. In addition to contacts between researchers and the registry organisation, a prerequisite for successful implementation is the existence of good clinical contacts or networks within the subject area.

Support for general planning of an RCT can be found in our step-by-step guide to the research process.

A first step in planning is to clearly identify the scientific question(s) to be answered by the study and consider whether an R-RCT is appropriate, preferably via a synopsis. Then the appropriate register should be identified and contact should be made to the registry controller. A joint meeting is then held between the researcher (and contact person) and a representative for the registry (e.g. registry holder, product owner and statistician). It discusses, among other things:

  • The research question (scientific question)
  • What is in the registry
  • Variable list for registry data
  • Potential requirement for other registries
  • Whether registry data alone is sufficient or whether there is a need for an EDC system.

If the study qualifies as a clinical trial, i.e. if medicines/medical technology products are involved, discussions are needed on what regulatory requirements apply and how it will be ensured that these requirements comply with the governing regulations (information on this can be found in our step-by-step guide on the research process). The meeting ends with a decision on the further planning of the study.

Examples of points to discuss in relation to the registry could include:

  • The outcome measures of the primary question and whether study-relevant variables have sufficient coverage/ are mandatory to report in the registry.
  • Are all study patients included in the registry, i.e. do all variables have the same source or are additional sources needed?
  • What is the coverage of the specific target study population in the registry?
  • Are the data in the registry of sufficient quality, in terms of external and internal validity, to form the basis of research on?
  • How fast do clinics record data in the registry? What is the time delay between an event (e.g. bleeding/myocardial infarction/other complication) and its actual registration in the registry?
  • Direct registration is desirable, but in some registries it is routine to register later and this must be considered when planning.
  • The compliance of the registry with the medical record should be considered. Is the registry continuously monitored?
  • How much of the registry data matches the medical record data?
  • No variables used in the study should be updated, neither registry variables nor study-specific variables, during the study without discussing and documenting the consequences of these changes.
  • Are there study-specific costs for an R-RCT in the registry?

The researcher applies to conduct the study by contacting the registry's steering committee. The steering committee assesses the need for the study and whether similar studies are planned by other parties. The registry steering committee decides whether the registry can be used as proposed and whether the registry is considered suitable for the study. Only when the registry has approved the study is it appropriate to apply for funding for the project.

Written contracts must be entered into between the parties concerned. How these are designed depends on the roles involved in the planning and the participating clinics in the study. The contract aims to regulate tasks, responsibilities and funding.

Documents to be produced during the planning phase

Research plan/Protocol/Clinical investigation plan (CIP)
In addition to the already existing template, include which registries and variables from registries will be used and how often the extraction from the registry will take place. Describe how registry extractions in the study is handled with respect to study data.
Template for CIP

Subject information
In addition to the already existing template, include which registries and variables from registries will be used and how often the extraction from the registry will take place. There must also be consent from the subject to obtain data from registries.
Template for subject information

Risk analysis
Risk analysis in addition to already existing template, include for example the risk of delayed entry into registries or changes in registries affecting the study. There is more information on risk analysis in our guide to the research process.
Step-by-step guide to the research process

Application for ethics approval
Application for ethics approval that includes a list of variables, data extraction, if extraction is done with social security numbers, where and how long the code key will be stored (important when following up via government registries).

Other documents to be produced are:

  • Statistical Analysis Plan (SAP)
  • Data management plan (DMP)
  • Event and variable specification (CRF)
  • Data Dictionary (resulting in a data warehouse for the development of a technical solution proposal/study application).
  • Monitoring plan (if applicable)
  • Data handling report (DHR)
  • Check specification

Planning is carried out to develop a protocol and all parties/roles (e.g. researchers, product owner, contact person, statistician, data manager, registry holder, monitor) attend a meeting to agree on a final protocol.

Technical implementation

Based on an approved and agreed study protocol and study requirements, a technical solution proposal for the study is presented in cooperation with stakeholders. The proposed solution is presented to the researcher who either approves the proposal or requests adjustments.

Implementation of the trial in registries

  • Based on the technical solution proposal and discussions with researchers, the product owner develops a set of requirements for the technical solution/study application, which then forms the basis for implementation and validation.
  • The work is planned and resourced. During implementation, the contact person acts as a link between the researcher and the product owner.
  • The product owner contacts the system developer who implements the study-specific features needed in the registry. Examples of functions:
    • Screening and randomisation function
    • Data capture
    • Study-specific variables
    • Changes to the normal workflow of the registry
    • Standard reports
    • Clinic management.
  • The system developer implements study-specific reports.
  • The product owner is responsible for the documentation of the technical solution/study application.
  • If data comes from external sources, the product owner can provide support to make integration possible.

Acceptance test and validation of solution

  • The researcher gets access to a test environment where it is possible to see how the technical solution/study application will work in the registry and in the daily work based on a test protocol. At this point, the researcher can either accept the solution or request an adjustment to it.
  • Internal test and validation
  • Potential testing of the solution by data management.

All elements of the technical solutions/study application must be tested and approved by the researcher.

Management of technical solution and support

Operational monitoring of the study application
The technical solution/study application and its database must be available when a patient is screened and data is sent to the study. This requires that the product owner ensures continuous operation and establishes procedures for error handling and checking the functioning of study functions after updating the registry. Procedures for backup of the database and access to the database shall also be established.

Adjustment and bug fixes
Most often, something will need to be adjusted when the solution starts to be used. There may also be errors in the implementation that were not detected during development. Because of this, there needs to be resources to make new versions of the technical solution/study application.

Adjustment of the EDC if necessary

Support to registries and EDC users
The study is not primarily a part of the registry and therefore the registry's support cannot be used for non-contracted issues. It is the researcher's responsibility to ensure that support is available. Typical questions that must be answered are:

  • How should study-specific variables be recorded?
  • Who should have access to study data?

Depending on the type of study, it is of utmost importance that all necessary approvals are in place. More information on this can be found in our step-by-step guide to the research process.

Step-by-step guide to the research process

In order to start participating clinics, a number of activities must be in place. These are dependent on each individual study plan.

Before the start of the study, essential documents should be in place, such as contracts and permits for the study.

Each clinic is set up through an initiation meeting (more information on this can be found in our step-by-step guide to the research process). In a start-up phase, it is useful to start with one study site to check the feasibility before a gradual implementation of the other study sites. Management of the technical solution/study application and support (control of the person who can manage the registry) should be ongoing. The study should be able to activate more study sites over time.

The study database in an R-RCT often consists of an aggregation of data from an EDC database, data from quality registries and cross-checking with other registries and data sources. At the end of the study, each data source is locked. Data from the quality registry are delivered through data extraction or directly to the study database. The study database is checked for any inaccuracies/missing information and can be corrected if there is evidence to support the correction and an explanation for the correction is provided. It is not possible to correct incorrect entries directly in the quality register as this involves direct access to personal data. Corrections can therefore only be made in the study database. Once the study database is clean, it should be locked for analysis and no further corrections must be made. A ‘clean file’ meeting is held where all protocol deviations are recorded.

For an R-RCT, the following should be considered:

  • Registration in quality registries is often delayed. Before the end of the study, clinics should be encouraged to receive all follow-ups and ensure that registrations in the registry are completed for the final export of data. A final date for the completion of the last addition to the registry should be communicated.
  • Study data from registries should be provided to the relevant clinic and archived there.
  • In order not to increase the time and complexity of the registry management, the specific study solution should be removed from the registry implementation.
  • Once the study is completed, the study service is removed from the production environment. This also includes the ability to access the service, database, safety backups and monitoring.
  • A quality registry cannot be used as a surface for archiving research data and must be archived by the entity responsible for research.

Our step-by-step guide to the research process provides information on analysis, publication and archiving.

The research process