Study design of the Swiss HIV Cohort Study
The Swiss HIV Cohort Study (SHCS) is a prospective multicenter cohort study enrolling adult people living with HIV in Switzerland [15, 17]. The study was launched in 1988, is approved by all local research ethics committees. Written informed consent was obtained from all participants. Clinical, laboratory, epidemiological and lifestyle information is collected during bi-annual follow-up visits in all patients. All medication including HIV treatment, co-medication and vaccinations are reported in the SHCS. Starting in April 2020, the SHCS dynamically introduced and adapted SARS-CoV-2 relevant information, including information regarding SARS-CoV-2 testing (polymerase chain reaction, tests for SARS-CoV-2 antigen, and antibody), infection, as well as vaccination. In 2018, rollout of an electronic data capture tool started, enabling physicians and study nurses to enter patient information electronically into the database. The SHCS data capture tool uses the Django Web Framework, a high-level Python-based web framework built for development of applications, which manages all parts of application development, from database back-end to user-friendly front-end [18]. The Django Framework offers the possibility for the development of customized tools for data entry, data monitoring, benchmarking and quality checks. With its modular design, one can implement independent tools and features within the productive environment and make them visible to specific subsets of users. The SHCS covers around 75% of all individuals on antiretroviral therapy in Switzerland and is representative of the HIV epidemic in this country [15, 17].
Study design of the Swiss Transplant Cohort Study (STCS)
The Swiss Transplant Cohort Study (STCS) is a multicenter, prospective cohort study, launched in 2008, enrolling all patients receiving a solid organ transplant in Switzerland (transplantation centers: Basel, Bern, Geneva, St. Gallen, Lausanne and Zurich) [16]. The STCS was approved by the local research ethics committees of all participating institutions, and all participants provided their written informed consent. The STCS uses a data capture tool enabling study nurses at the transplant centers to enter patient information electronically. In line and close collaboration with the SHCS, the STCS decided to migrate the legacy system to the Django Web Framework and will soon use it for capturing clinical data [18]. The STCS also implements the requirements of the Swiss Transplantation Act for nationwide follow-up monitoring of all transplanted patients since 2008. For this purpose, a minimal dataset, i.e., baseline information about the transplantation and patient characteristics, is collected from all solid organ transplant recipients in Switzerland according to the legal requirements. For patients who provided their written informed consent to take part in the STCS, the full research dataset, i.e., information about follow-up visits and biological samples, is collected. In regard to Covid-19, the STCS implemented a targeted system to capture all Covid-19 cases in organ transplant patients since the beginning of the pandemic.
Design of the pilot trial: Corona VaccinE tRiAL pLatform (COVERALL)
We set up the COVERALL trial platform and customized it for the first pilot trial to test the functionality of the trial platform (see Fig. 1 for an overview of the study timeline). The main focus was to determine the duration of the trial set up, i.e., time from deciding which interventions will be tested until the first patient is randomized, as well as the time of patient recruitment, i.e., time from activation of the first study site until (i) 40 patients and (ii) 380 patients (the targeted trial population) were randomized. Moreover, we were interested in the following pre-specified outcomes: Patient consent rate, proportion of missing data at baseline and proportion of missing data for clinical outcomes. The COVERALL pilot trial is a parallel two-arm, open-label, non-inferiority randomised clinical trial with the aim two compare the first two licensed SARS-CoV-2 vaccines in Switzerland [20]. Eligible patients enrolled in the SHCS or STCS were approached by study personnel, and written informed consent for participation in COVERALL was obtained.
Data infrastructure
The trial platform uses the data infrastructure of the two well-established systems of the SHCS and STCS. These systems were connected to a new data collection tool developed with Research Electronic Data Capture (REDCap). The platform was customized for a first pilot trial comparing the messenger ribonucleic acid (mRNA) vaccines Comirnaty® and Spikewax® in the SHCS and STCS, termed COVERALL [20]. The innovation of this project is to perform automatic patient selection, randomization, and automatic transfer of baseline data to the trial platform by using the available data infrastructures (SHCS and STCS) and the REDCap data collection tool. We summarized the workflow in Fig. 2. We outline the detailed steps of the data infrastructure in the following paragraphs.
Flagging patients within the SHCS: In autumn 2020, we extended the SHCS electronic data entry tool by a feature allowing for integrating nested studies in the workflow of a regular SHCS follow-up visit. The users are made aware of the existence of substudies within the SHCS, eligibility of patients is indicated. For COVERALL, a nested trial with three levels of prioritization of patients was added (see Fig. 3A). For this, at COVERALL study launch, an algorithm was executed to assign a priority (high, medium, low) to each active patient, based on the most recent laboratory and clinical information and the current recommendations given by the Federal Office of Public Health:
-
1.
High risk: All patients aged at least 75, the most recent CD4 count below 200 cells/µL, or the latest HIV viral load measurement being detectable (> 500 copies/ml).
-
2.
Medium risk: All patients (not in the high risk category) with a past coronary heart disease, diabetes, hypertension, metabolic syndrome, low glomerular filtration rate, or high body mass index.
-
3.
Low risk: All remaining active patients not in the high or medium risk category.
A list of eligible patients in the three categories was produced and integrated into the Django system, with dynamic updates indicating whether the patient is participating (see Fig. 3B). The nested study tool was set to be visible for all physicians and study nurses participating in the COVERALL study, i.e., only to a subset of the participating SHCS study nurses and physicians. On the patient overview page, the user is made aware of the COVERALL study, and the risk category is indicated. Clicking on the respective link, the user can navigate directly to the nested study view, where patients can be included in the study with only one click (see Fig. 3C).
Patient selection and baseline data transfer for the STCS: Before the COVERALL study launch, baseline data needed for the randomization algorithm (patient STCS identifier, sex, birth year, center, type of organ (kidney or lung), immunosuppressive treatments, date of transplantation) was extracted from the STCS database and uploaded to the REDCap platform.
Log-in for users to REDCap: Before the COVERALL study launch, a list of all participating study nurses and physicians was requested by the participating SHCS and STCS centers. A file including names and e-mail addresses was then uploaded to REDCap to automatically create REDCap user accounts. All users received an automatic email by REDCap with log-in information. User roles including access rights were then assigned to the study nurses and physicians.
Inclusion of new SHCS patients and follow-up information: For the SHCS, an application programming interface (API, see details below) was implemented to allow communication between the SHCS electronic data platform (Django) and REDCap. Patients can be added to the COVERALL study in the SHCS Django (see Flagging patients within the SHCS above). The user is directly navigated to the REDCap platform and, after log-in, directly redirected to the respective patient (see Fig. 4A). To enter follow-up information, the user can navigate to the patient file using the links in the SHCS Django, or navigate on the REDCap dashboard, where information regarding the progress about inclusion and follow-up process is given (see Fig. 4B). For the STCS, the same API was not yet implemented in STCS Django because the system is not yet operational. Therefore, subject selection and baseline data of all patients was uploaded to REDCap before the COVERALL study launch. To include a new patient or to enter follow-up information, the STCS user needs to directly navigate to the main REDCap interface, log-in, and search for the respective patient STCS identifier in the REDCap search tool (see Fig. 4C). After filling out eligibility and exclusion criteria, the patient was then randomized and was hence included in the COVERALL study. After this, follow-up information and adverse events could be entered. On the study dashboard, progress of the inclusion and follow-up process is continuously monitored (see Fig. 4D).
API and trigger: In the SHCS, no patient information was available in REDCap at COVERALL study launch, baseline information is transferred stepwise and automatically only after including the patient via the SHCS Django-REDCap API: For inclusion of a patient, the “Include patient”-button (see Fig. 3C) triggers an API call executing the following tasks:
-
1.
COVERALL study population: All SHCS patient identifiers, including the allocated treatment for already randomized patients, are obtained from REDCap.
-
2.
New patient: Baseline data of the new patient is fetched through the SHCS Django system
-
3.
Balance of treatments: Based on the current study population and the baseline information of the new patient, the treatment, which minimizes the overall imbalance, is calculated, termed “imbalance minimizer” (see Minimization Algorithm for Randomization below).
-
4.
Baseline data transfer: Transfer of baseline data of the new patient to REDCap, including the before calculated imbalance minimizer.
After inclusion of patients, the “Include patient”-Button changes to an “Open in REDCap”-Button, providing a direct link to the patient dashboard of the REDCap platform (see Fig. 4A). In the case of the STCS, baseline data of all patients was uploaded before study launch. For every change in an existing record, e.g., verifying inclusion and exclusion criteria for COVERALL, a request to the Django system is triggered, sending a message with the patient SHCS identifier of the modified patient. The patient information is obtained via the API. In case the patient should be randomized, i.e., inclusion criteria and exclusion criteria are correctly filled out, the imbalance minimizer is calculated based on the previously randomized patients. Then the patient can be randomized.
Minimization algorithm for randomization
The main goal is that patients are randomized to the two available vaccines, Vaccine A (Comirnaty®) or Vaccine B (Spikewax®) such that the imbalance of the two vaccines is minimized regarding the four co-variables:
-
Age: ≥ 65 or < 65 years old
-
Sex: male or female
-
Study center: Zurich, Basel, Bern
-
Immunosuppression status:
While REDCap offers a built-in tool for randomization, i.e., equal chance for all choices, the minimization algorithm had to be developed outside REDCap. In particular, imbalance minimizer was calculated using the R software [21]: The four co-variables are weighted equally and the treatment leading to the smaller total imbalance in the four categories is chosen [22], i.e., Treatment A or Treatment B. In case of equal balance, the imbalance minimizer is set to Both. The variation (total imbalance) of each category is quantified as sample variance. For the SHCS, the imbalance minimizer is calculated via the API when including the patient via Django (see API and trigger). For the STCS, the imbalance minimizer is calculated when the trigger is executed (see API and trigger). Based on the imbalance minimizer, the treatment is assigned randomly with unequal probabilities using the sample function in R. In case the imbalance minimizer is ‘Treatment A’, chances to get assigned to ‘Treatment A’ are 80% and chances to get assigned to ‘Treatment B’ are 20%, vice versa in case the imbalance minimizer is ‘Treatment B’. In case the imbalance minimizer is ‘Both’, chances are 50% for ‘Treatment A’ and 50% for ‘Treatment B’.