EDC — the future of DCT? — Part 2
Doug Bain, KCR Chief Technology Officer
In part 1 of this 2 part article, I discussed the elements that an effective EDC system required in order to be considered an appropriate base for future use as part of a clinical trial support solution, including DCT — Decentralized Clinical Trials. In Part 2, I will talk in more detail before reaching a conclusion.
Before I continue, I should explain for those that do not know me that I have previously worked in different capacities with 5 different EDC systems. Most recently I spent 7 years developing a single platform clinical trial lifecycle solution. The opinions I share in these two articles reflect both my successes and failures. These are my personal opinions. I intend for them to be challenged.
Today, I am responsible for the assessment and use of EDC & DCT together with other eClinical technologies at a successful mid sized CRO — KCR.
EDC and Workflow
The vast majority of EDC systems have static, loosely configured workflow — I have expanded on workflow in last weeks post on that topic. Medidata Rave, as an example, was quite powerful here being able to support, through configuration, many combinations of sequences of data entry, cleaning, review and locking.
This type of ‘admin panel’ configurable workflow is typically adequate for EDC because in their context, the variances in the sequences of the entry and cleaning of data are limited.
Adding in other influencing elements such as Recruitment, Randomization, eCOA and Scheduling then things start to get a bit spicy. The static workflow configuration becomes too restrictive. Most systems simply do not support it. So.. you can enter data into EDC before the patient is screened. You can dose a patient before a patient is Consented. You can lock a patient even before all external data is received. EDC is typically a disconnected ‘after effect’ systems.
Of course, you aim to perform activities correctly. Today, we use CRA Monitors and trained site staff to ensure that activities for the study occur in the correct order. You have Biostats write software that clean things up later. You use Advanced dynamics to present forms and fields based on previous entries. However, despite these types of automation, the vast majority of costs in clinical trials can be attributed to the checking and tracking of data that is either transposed or copied across systems.
When it comes to performing Decentralized clinical trials, you cannot afford the luxury of manually applying monitoring or site staff to fix issues retrospectively.
When you capture data at source, the time and method of capture of that data becomes part of the science itself. EDC is a clerical system that records a transcription of data from typically other sources. DCT solutions are systems that can influence the data itself.
DCT therefore mandates live workflow to ensure activities occur in the right order by the right stakeholders.
So — to the question — should these activities be part of an EDC system?
EDC for Decentralised Trials
Ok, so we have discussed in part 1 some of the core features that define an EDC system that has scope to go beyond simply capturing eCRF data. So what else is required as part of an EDC system to make it part of a DCT solution?
Today, EDC increasingly provides a set of features that allow them to meet their business requirements in an integrated fashion. For instance, often they provide native and even workbench dictionary coding (MedDRA / WhoDrug). Some support Randomization and even Trial Supply Management. They must provide Clinical Data Management functions and deliver SDTM data, they must be part of an eCOA solution. Not all vendors successfully extend their EDC products and there are good reasons why. Most create or buy entirely separate products.
So — here are three reasons why a vendor cannot or will not extend their EDC to DCT;
1). Thinking ‘Not EDC’.
Old EDC does not define the requirements for new EDC!
Many of the EDC vendors look at the legacy systems and decide to simply create a system that is a minor delta change from these systems, using new tech. ‘I have created a better edit check mechanism that ever before’, or ‘my eCRF migrator saves days of effort for Data Management’. Old EDC does not define the requirements for new EDC!
They branch off separate solutions to form the other parts without truly understanding and addressing the integrated nature of the activities that each solution should deliver together with EDC.
Even when a vendor does understand, the nature of EDC where individual trials and sponsor demands trump product evolution, the idea of strong integration can be pushed out to sometime… never. I bet that most Chief Technology Officers at EDC companies have a long list of X, Y and Z planned strategic capabilities that will never go beyond ‘X’. Metadata integration is usually in this unachievable list.
3) The EDC base is only suitable for EDC functional support
When you think about developing purely an EDC system today — you will develop it with configuration designed to meet the needs of EDC alone. If you step back beforehand and consider the functional requirements of the entire lifecycle of a clinical trial, the architecture and design decisions you would make would be significantly different.
Here is a common scenario. 1). Your company creates a good EDC solution. 2). You sell sufficiently to raise funds and raise your profile. 3). You have a rapidly increasing demand for your EDC software and you have cash in the bank to expand. 4). Your clients demand enhancements to your core EDC platforms in all areas. Your core team is stretched to meet demands. You create other teams to build the other functional areas. You produce multiple silo solutions under a common brand.
This is true for most legacy systems today. It is most common that an ePRO system, and eConsent solution and an EDC systems have separate data and metadata. This means typically that the sites must manually ensure that the patient entered into EDC align with patients entered into ePRO and eConsent. However, it stifles expansion and limits ease of use.
Decentralised Clinical Trials Integration
One take away from my 7 years developing a Decentralised Clinical Trial (DCT) platform (Clinpal) was that a successful DCT solution must contain EDC to be truly scalable.
I should pause here and say that most sponsors are not ‘looking’ for a DCT with EDC — often they have invested in something else — however, when I look back at DCT studies with integrated EDC versus those that were not, it was those with integrated EDC / DCT that created the best sponsor, site and critically patient experience, and that were most cost effective. The reason that the Clinpal platform was not massively successful in the early days (2014–2019) was sponsors were buying DCT point solutions to add to other pre-existing technology. The idea of acquiring a Platform for enterprise DCT was not broadly understood .
Also learning from history from large companies — the early big Medidata clients co-existed Rave EDC with legacy CDMS solutions. It was only when Rave became the defacto standard for EDC AND included adequate CDM features that the legacy CDMS systems were phased out. I believe the same can apply for DCT + traditional EDC.
DCT Hybrid demands integrated powerful EDC
The vast majority of DCT trials will be Hybrid. I would go so far as to predict that at least 75% of clinical trials will be hybrid by 2030. Part site, part remote.
A successful Hybrid DCT relies very heavily on an engaged and connected site. Forget doing away with sites — remember that patient care & treatment comes first — in many research settings, that requires sites, doctors and nurses with the infrastructure of a health care facility.
For Hybrid DCT to work, sites need to see the world the patient sees. They are responsible for their patients and the data they provide. They need to be carrying out activities for the trial that reflect the activities the patient is being asked to perform. This cannot be achieved with ‘another’ system that they occasional go into. It needs to be part of the sites daily activities. One system — not just one vendor — One system.
To help emphasis this, below are a list of activities in EDC that must reflect DCT patient activities;
- Enrolment / Consent
- Schedule of events — by role
- Symptomatic Adverse Events (see recent FDA / EMA guidance)
- Visit scheduling — virtual and non virtual
- ePRO data and compliance reviews
- Site / Patient Communication
- Wearable compliance
This list is non exhaustive.
If the features listed above lie separately from EDC, DCT will not achieve Enterprise scalability.
What does the future hold?
So — applying logic above to current companies, will we see current EDC vendors like Medidata, Castor and Veeva achieve transformative success in DCT, or, will the new heavily funded companies like Medable, Science37 and Thread win the shoot out?
Much as I would like to see new transformative companies shape the future, I would probably go with the existing vendors for three reasons -
1). they have working EDC solutions and in theory can add the DCT functions as functional solutions
DCT companies like Medable, Science37 and Thread do not have full blown EDC with all the detailed aspects required in order to be successful. Yes, they will work together with the legacy vendors when running Hybrid studies, but the cost, complexity and efforts involved will leave a bad taste for most sponsors and sites for the next few years.
2). No ePRO company in the past has written a good EDC or CDM solution.
Will the heavily funded DCT companies buck that trend? The challenge here is to achieve a patience for heavy investment for 3–5 years. This is difficult to maintain especially with a need to spend another 5 years to break into the credible enterprise EDC market space.
3). Very few DCT companies have a viable organic business. Investments are being made for the future. If the investment cash is exhausted within the first 6–8 years, then they will flounder as the lifecycles are long even within established clinical research areas and even longer for emerging technologies and methods such as DCT.
My ultimate hope working as a CTO for a growing and successful CRO is that we see a new type of DCT solution that builds from a core platform and then leverages this core in the development of component parts including EDC that share data/metadata and user experience in order to achieve a true clinical trial lifecycle supporting tools for all stakeholders.
So — in summary, my own personal predictions that I know will not be popular for some, are that todays well funded dedicated DTC companies that have failed to build their products from a solid base platform will burn bright for a while but ultimately struggle to achieve sufficient business to thrive.
The traditional eClinical vendors will continue to show some traction building from their existing business despite significant efficiency and easy of use challenges.
By 2027, a fully cloud platform multi-modality SaaS company that is dedicated towards all the major aspects of CDM/EDC and DCT on a common base with end to end clinical trial lifecycle support for patients will win the prize of supporting truly transformative clinical research.
Lets wait and see whether this will come from a new vendor, a current DCT vendor or an existing EDC company.
- This article was originally published on LinkedIn on March 17, 2022
KCR is a clinical development solutions provider creating value for biotechnology and pharmaceutical organizations. Founded in 1997, our expert teams support clients with full-service clinical development capabilities across three main areas: Trial Execution, Consulting and Placement. KCR operates across North America, Europe, and Australia, with main office locations in Boston, US, Berlin, Germany, and Warsaw, Poland. Our geographical coverage across 25+ countries, cutting-edge technical capabilities and tailored offerings allow for the optimized delivery of solutions to develop life-changing therapies. KCR offers access to an estimated population of 1.1 billion people. For more information visit www.kcrcro.com.
We see the human behind every number.