Steps in the R-RCT process

About the steps in the R-RCT process

The steps in the R-RCT process are based on joint meetings between different roles for the development of the trial and technical solution/trial 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 trial 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 controller, 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 trial 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 trial.

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

  • The outcome measures of the primary question and whether trial-relevant variables have sufficient coverage/ are mandatory to report in the registry.
  • Are all trial 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 trial 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 trial should be updated, neither registry variables nor trial-specific variables, during the course of the trial without discussing and documenting the consequences of these changes.
  • Are there trial-specific costs for an R-RCT in the registry?

The researcher applies to conduct the trial by contacting the registry's steering committee. The steering committee assesses the need for the trial and whether similar trials 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 trial. Only when the registry has approved the trial 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 trial. 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, please 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 trial are handled with respect to trial data.
Template for CIP

Subject information
In addition to the already existing template, please 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 trial. 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 a civic registration number, 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/trial application).
  • Monitoring plan (for clinical trials)
  • Data handling report (DHR)
  • Checking specification

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

Technical implementation

Based on an approved and agreed trial protocol and trial requirements, a technical solution proposal for the trial 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/trial 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 trial-specific features needed in the registry. Examples of functions:
    • Screening and randomisation function
    • Data capture
    • Trial-specific variables
    • Changes to the normal workflow of the registry
    • Standard reports
    • Clinic management.
  • The system developer implements trial-specific reports.
  • The product owner is responsible for the documentation of the technical solution/trial 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/trial 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/trial application must be tested and approved by the researcher.

Management of technical solution and support

Operational monitoring of the trial application
The technical solution/trial application and its database must be available when a patient is screened and data is sent to the trial. This requires that the product owner ensures continuous operation and establishes procedures for error handling and checking the functioning of trial 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/trial application.

Adjustment of the EDC if necessary

Support to registries and EDC users
The trial 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 trial-specific variables be recorded?
  • Who should have access to trial data?

Depending on the type of trial, 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 trial plan.

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

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 trial site to check the feasibility before a gradual implementation of the other trial sites. Management of the technical solution/trial application and support (control of the person who can manage the registry) should be ongoing. The trial should be able to activate more trial sites over time.

The trial 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 trial, each data source is locked. Data from the quality registry are delivered through data extraction or directly to the trial database. The trial 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 trial database. Once the trial 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 trial, 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.
  • Trial 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 trial solution should be removed from the registry implementation.
  • Once the trial is completed, the trial 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