Clinical study protocols

Describing decentralised components

14 min read

A protocol that uses decentralised components, from telemedicine to direct-to-patient shipping, should describe and justify each one. What it says about a component rests on first scoping that component: why it is used, who uses and supports it, what it provides, where and when it is used, and how its end users engage with it.

From rescue tools to designed-in components

During the COVID-19 pandemic, trial teams used decentralised components as rescue tools to continue trial activities offsite when onsite visits were impractical. Given the public health emergency, regulators supported this approach. The MHRA, for example, stated that it is entirely feasible and acceptable for a protocol to appropriately describe both the procedures for regulatory decision-making and flexibility in how clinical visits, monitoring of participants and follow-ups are implemented, and that the use of decentralised and digital or virtual elements in a study should be considered.

By March 2023 the use of decentralised components was becoming widespread, and protocols were moving from using them as rescue tools during the pandemic to including them as integrated decentralised research methods. One author held that the resilience that trials using decentralised components had shown, together with their benefits to participants and their economic benefits, would accelerate that transition. In the same author's view, the protocol development process must be updated to enhance the clarity, completeness and replicability of protocols that incorporate decentralised components, and, as adoption grows, it needs to keep pace if protocols are to keep their effectiveness.

In one protocol writer's view, COVID-19 protocols are not a good source of information on how to incorporate decentralised components into a protocol, because the motivations behind them were different. Having incorporated them once is not enough, and incorporating them easily will take time and a better understanding of what is needed. In March 2023 there was no consolidated guidance on what a protocol should say about decentralised components. No one was yet quite sure what absolutely had to go into it.

What ICH E6(R3) Annex 2 asks the protocol to describe

ICH E6(R3) Annex 2 gives additional good clinical practice considerations focusing on trials that incorporate decentralised elements, pragmatic elements or real-world data, and refers to such operational approaches, design elements and data sources collectively as methodologies. Appendix B of the guideline describes the topics a protocol should generally include, and Annex 2 adds that further consideration may need to be given to the protocol and protocol-related documents when various methodologies are used, so that all parties involved in the trial's conduct are adequately informed. Under Annex 2, the sponsor should:

  • Describe the specific design elements, data sources and, where appropriate, operational approaches adequately in the protocol, justify the appropriateness of their use and briefly explain the rationale, fitness for purpose and feasibility of the methodologies. Protocol-related documents can supplement these descriptions.
  • When considering incorporating trial-related activities that are part of usual clinical practice (pragmatic elements), assess whether that approach is fit for purpose for use in the trial and complies with applicable regulatory requirements. Where such activities are incorporated, make sure the protocol clearly describes how, by whom and under what circumstances they will be performed, so that they are well understood and appropriately implemented.
  • Consider in the trial design the impact of any variability within or between data sources or practice settings, such as sources with different data collection timings, and discuss it in the protocol or a protocol-related document such as the statistical analysis plan.
  • Consider the methodologies used when determining what training and technical support the investigator, site staff and participants need.
  • Describe in the protocol and, where applicable, protocol-related documents how safety information will be collected from the variety of data sources, such as digital health technologies and in-person or remote visits, how information suggesting a potential safety concern will be identified and made available to the investigator in a timely manner, and what the investigator should then do. Give this information to the investigator in a way that helps inform their decisions on eligibility, treatment, continued participation and the safety of individual participants.
  • Describe in the protocol the modalities of the informed consent process, such as remote or in person.

Guidance from ACRO, the EU and the FDA

In March 2023 one protocol writer held that the best guidance for incorporating decentralised components was the recommendation paper of the Association of Clinical Research Organizations (ACRO). What is allowed in which country is a major pain point in Europe, and the paper's appendix gives a traffic-light overview of it.

In December 2022 the European Commission, the Heads of Medicines Agencies and the EMA published recommendations that aim to facilitate decentralised trials while safeguarding participants' rights and well-being and the robustness and reliability of the data collected, as an outcome of their joint initiative Accelerating Clinical Trials in the EU (ACT EU). The recommendations include an overview of national provisions for specific decentralised elements. They are a first step towards clarifying the use of decentralised trials in the EU and EEA and are expected to evolve as knowledge and experience grow, with the overview of national provisions updated continuously.

The FDA's December 2021 guidance on digital health technologies for remote data acquisition gives recommendations for selecting digital health technologies suitable for a clinical investigation, validating them and using them to collect data, and for identifying and managing the risks of their use in trials. Familiarity with new guidance on decentralised trials and digital health technologies is essential for medical writers preparing protocols, and it helps them adequately describe the study endpoints, the efficacy and safety measures assessed with a digital health technology, and the assessment schedule. The FDA's guidance on decentralised trials, in which activities take place outside clinical sites, helps medical writers address issues of protocol deviations, baseline comparability and remote assessments.

Scoping each component

Decentralised components can include telemedicine, wearables, electronic consent, electronic clinical outcome assessments, home healthcare and direct-to-patient shipping.

Understanding the scope of each trial activity, and how the activities relate to and interact with each other, is one of the most challenging aspects of protocol development, and decentralised components are no exception. ACRO's decentralised trials toolkit includes a map of common methods that can help the team see what is available and which methods work together, and further resources are ACRO's quality by design manual for decentralised trials and the Digital Medicine Society's playbooks for digital clinical measures and digital healthcare. These resources can help the trial team discuss and understand what using a component requires, and, once that is understood, the component's information has to be incorporated into the protocol.

Each component's scope can be established by a scoping exercise in six steps, each with its key questions:

  • Why: Why is the component suitable for this research question? Is the anticipated trial data quality appropriate for this study?
  • Who: Who is the component's end user? Who supports the data flow, from point of collection to final storage? Who provides training?
  • What: What physical or digital items will be provided? What data will be collected? What training will be required?
  • Where: In what geographic regions will the component be used? In what physical location, in relation to the end user, will it be used?
  • When: When will the component be used in a given period, such as one day? How often in that period will data be collected, discretely or continuously?
  • How: How will end users interact with the component? How will operational variability be controlled?

The exercise is broadly aligned with the SPIRIT 2013 statement and with the TIDieR checklist and guide for describing interventions. TIDieR is aimed at describing interventions in publications, but its objective of complete reporting and replicability is comparable to the protocol's, so it serves as a foundation for identifying the content needed to scope the components.

The why is the first and most important point in establishing a component's scope. Its first question, whether the component suits the research question, calls for a clear justification of why decentralised components are used in the trial. Its second, whether the anticipated data quality is appropriate, considers whether the results generalise, as when a technologically literate population may not represent the wider target population; how far outcomes vary with the component's flexibility and participants' familiarity with it; whether continuous collection produces challenging datasets and unnecessary participant burden; and how complete the data will be. The two questions form the foundation of each component's risk-benefit assessment, which ACRO's risk assessment considerations template for decentralised trials, part of its toolkit, is meant to aid. The EMA's guideline on computerised systems and electronic data in clinical trials reinforces this, stating that an approach used to reduce risks, such as adopting decentralised components to reduce the risk of dropout, should be incorporated in the protocol design.

The who is the end user and anyone who supports the end user, the data flow or the training. For electronic devices or questionnaires the end user is likely to be the participant but could be a caregiver, a family member or another individual, while for home healthcare or electronic clinical outcome assessments the end users are likely to be investigators, nurses or other healthcare professionals. Summary details of those who support the end user, the data flow or the training may be needed to show that a robust process will be in place. For a wearable or connected device whose end user is the participant, for example, site staff may give the training at enrolment or by virtual means, and the device vendor or the sponsor may manage the data flow from the device.

For the what, physical items may include materials and training documentation for the end user or those supporting them, and digital items may include apps, the data flow and troubleshooting support processes.

For the geographic region, a trial may be multiregional or run in a single country whose states have some autonomy, as in the United States. In the year or so before March 2023, regulatory agencies, including those of Denmark, the United States, India and Switzerland, began to release dedicated guidance on decentralised trials or guidance that addresses certain components, and as adoption grows, countries are likely to release or update guidance on which components can be used and under what conditions. For the physical location, a participant may use a wearable or connected device for the whole waking period, for example, while a nurse may conduct home healthcare visits at the participant's home or another agreed location. The physical location should be understood to describe the intended use and any risk mitigation: where home assessments are required once in the morning and once at night, for example, the mitigation may include reminders and strategies for a participant who is away from home for a long period, for work or on holiday.

The when is how often the component is used in a given timeframe, such as the number of times in a day, and how often data are collected. Collection can be discrete, at a single point in time such as a once-daily assessment, or continuous, such as a wearable or connected device that monitors heart rate for the whole time the participant is instructed to wear it.

For the how, the trial team must understand clearly how end users are expected to engage with the component under ideal conditions, and control, to a limited degree, its variability in real-world operation: what happens, for example, if a participant does not complete a critical assessment on waking, and whether a reminder follows. The more critical the component is to the trial's why, the more this matters.

The information the scoping gathers may not all go into the protocol, since circumstances may require some details to be left out. The name of a wearable or connected device, for example, may be omitted where the trial is multiregional and local variability in the device is anticipated, and a cross-reference to a supplementary document is then preferable. Where the information on what is provided is extensive or likely to differ across geographies, a cross-reference to a supplementary document may likewise be preferable.

What the protocol says about each component

Categorisation of decentralised components remains fluid, and organisations may classify components and approaches differently according to business or logistic needs. Some of the most common categories are these:

  • Telemedicine, in a clinical trial, is the use of telecommunication technology between investigators and participants to conduct remote clinical assessments, such as physical or neurological examinations, the collection of clinical data such as the participant's assessment of the intervention's benefit, or discussion of remote data collection with digital health technologies. More broadly, telemedicine is the use of electronic information and telecommunications technologies, such as videoconferencing, the internet, store-and-forward imaging, streaming media and terrestrial and wireless communications, to support and promote long-distance clinical healthcare, patient and professional health-related education, public health and health administration. Data from telemedicine visits often support key endpoints, so the more critical the data, the more important their description in the protocol, including whether there is flexibility for onsite, telemedicine or remote visits. The more critical the data, the more likely the protocol needs to describe risk mitigation, such as multiple reminders or additional phone calls from the site so that telemedicine visits at critical time points are not missed.
  • Apps and technology have no formal definition. They are the communication or data-entry point, or both, between the site and the participant. Communication and data transfer between participants and investigators or other trial staff may use commercial or custom-made apps, which may be installed on a smartphone, tablet or laptop for telemedicine visits, wearable or connected devices, electronic clinical outcome assessments, home healthcare or other trial requirements. The device may be provided by the sponsor for the duration of the trial, as a provisioned device, or the apps installed on the participant's preferred device, under a bring-your-own-device option. The protocol needs no substantial detail on them, only enough to make clear what is provided, such as whether all data collection runs through one interface, such as a smartphone app, or through several; whether provisioned devices or participants' own devices are required or left to each participant's preference; and, where participants' own devices are preferred, what happens to an eligible participant without a compatible device. From a regulatory perspective, the risk-benefit of a provisioned device against the participant's own is complex and requires careful consideration.
  • Wearable or connected devices include static or worn devices that support remote data collection directly from the participant, such as actigraphs that monitor activity levels, or from their environment, such as air quality. They are also defined as electronic devices worn or carried on the body that let the user's personal data be monitored and measured through smart sensors embedded in the device. Their data can be stored locally or centrally, and the process from the point of collection to the point of final storage is part of the data flow. The EMA's question-and-answer document on good clinical practice states that a detailed diagram and description of the transmission of electronic data should be provided in the protocol, and ACRO's quality by design manual supports this. Further points of caution are describing any flexibility in how end users engage with the device, to accommodate a range of technology capabilities and of visibility or mobility, the data collection and validation capabilities, and the handling of missing or invalid data.
  • Electronic consent is an electronic method for seeking, confirming and documenting informed consent, through an electronic form that may include images, audio, video, diagrams and a digital signature. It also documents that the participant has been given the appropriate, non-coercive written information that supports their ability to give fully informed consent, and assent forms are another kind of consent form. A fully remote trial is likely to require electronic consent given remotely through an app, while a hybrid trial may require it remotely or at the site. The consent process does not feature heavily in the protocol, but the difference and variability of electronic consent compared with traditional paper consent warrant careful evaluation during protocol development.
  • Electronic clinical outcome assessments are the electronic capture of a measure that describes or reflects how a participant feels, functions or survives during a trial, as clinician-reported, patient-reported, observer-reported or performance outcome measures. Like paper clinical outcome assessments, each needs summary details in the protocol and consideration of how it will be accessed and by whom, and the SPIRIT-PRO extension describes complete reporting of patient-reported outcomes. Different end users may access them from different apps, which multiplies the data-flow considerations recommended for the protocol, and training needs may vary with the number of assessments and where users are located or trained.
  • Home healthcare is the wide range of healthcare services given to a patient in their home, typically during home health visits. Home healthcare by nurses, phlebotomists, physicians or other healthcare professionals can relieve some of the burden of participation by reducing or eliminating onsite visits. The challenges of incorporating it into the protocol fall into two categories. The first is flexibility in who may receive it: whether it is mandatory or optional in one or all geographies, whether it can be a flexible alternative to onsite visits by participant preference, and whether all participants are eligible, such as all those in a subgroup that has more assessments. The second is flexibility in where the visits take place, since a participant may not be comfortable with a healthcare provider in the home or may spend much of the day or week away from it, and other prespecified safe locations or local clinics may then be feasible alternatives.
  • Direct-to-patient shipping provides trial materials, trial interventions or both directly to the participant by home delivery. The shipment of clinical supplies and investigational medicinal products can go to the participant's residence or another agreed location, such as their work. Early engagement with the trial's supply-chain stakeholders is essential, to allow time for logistic and cost estimates and for establishing the process that protects personal data. The protocol needs to state clearly the preparation, handling, storage and accountability of medication and samples, and whom this applies to, since there may be geographic restrictions on where the component can be used.

Sources behind this topic

4 sources · 26 passages

Follow the evidence

Supporting passages

The source text behind this topic. Read it in context.