What makes an eClinical Platform?
By: Doug Bain, Chief Technology Officer at KCR
In the last 2 years, we have seen something like $700Million invested in clinical trial solution software companies. With only limited exceptions, a primary basis for the investment is for the creation of an enterprise platform. Companies, primarily in the Decentralized Clinical Trial space have shown some successes with point solutions and custom built apps, but they do not have the necessary platforms to scale to enterprise levels and to operate outside their own size (e.g. with tech transfer partner). Platforms are seen as the panacea to this problem.
Over recent years, the lack of a good definition for the word “Platform” in the context of clinical trial systems has resulted in the term being watered down to a mere marketing tag. Vendors are taking multiple systems, giving them a common logo and colour scheme, and calling it a platform — or worse — a “unified platform”.
This is damaging. It means that companies that are producing transformative solutions are being lost amongst the companies with big marketing budgets that do not.
In an attempt to address this, I am going to attempt to define the elements that can be combined to achieve an eClinical platform. This is aimed to allow readers to assess whether the system they are developing or licensing is capable of delivering the benefits that I believe are possible with a fully unified cloud platform.
First, let’s talk about benefits.
Benefits for Sponsors / CRO
For over 20 years, Sponsors and CROs have attempted to sticky tape disparate systems together in order to achieve efficiencies in clinical trials. Standards such as CDISC ODM have helped, but a fundamental lack of consistency in how each of these systems are setup and operated together with clunky old technologies that are not geared up to interfacing has meant that the results are patchy and expensive. Invariably, organizations have resorted to using the ‘get-out-of-jail’ card — using staff to key data two or more times and for other staff to check it. Horrible.
In an attempt to achieve greater clinical trial throughput, sponsor companies have looked at applying agile methods with the creation of self sufficient cross department study teams. This agile approach has some merits and has been successful in other industries. However, the silo nature of the technologies they are forced to operate within reinforce the former mode of operation leading to limited operational gains.
With a platform approach, interfaces may still exist, but they can work seamlessly and without programming aided with the sharing of metadata and the power of cloud technologies. Systems like Veeva Vault Clinical — CTMS with Veeva Vault Clinical — EDC have an interface that bi-directionally exchange both metadata and data, but the time to setup for each study is minutes and the programming is zero. In comparison, 20 years ago, I worked on an EDC system that sent data to the Merck CRISP/CTS system. Our interface design, build and testing took many months.
Benefits for Sites
It is not uncommon for an investigator site to be asked to use 5 different systems for a single clinical trial (EDC, ePRO, IRWRS, Doc Portal etc.) Sites do not willingly choose to use 5 systems. This frustration goes beyond just clinical research technology.
The status quo today is that daily site activities involve maintaining a list of all of the systems they need to login to together with usernames and passwords. For each system & trial when they login, they need to check for actions to perform, queries to answer and alerts to respond to. If you operate a large site with a pool of site coordinators you can imagine the frustration of the staff as they attempt to navigate System X, Y and Z for study A, System Y, Z and W for Study B etc. With a single platform, sites login and see all the activities they need to perform. They enter data once and not multiple times. They are system trained once for all studies and sponsors.
With the emergence of Decentralized Clinical Trial systems, combined with traditional technologies, this becomes even worse for sites.
If you gave the site the choice to use a single system, they would jump at it.
Benefits for Patients
Expanding this to the patient — they simply won’t use 5 systems. Today we often see separate systems for recruitment, eConsent, ePRO and wearables.
The greater the burden, due to the technology participants are asked to use, the more likely they will fail to engage, impair their compliance or even drop out of a trial.
A short-term answer to this patient vs. stakeholder platform question is whether one platform may exist for the patient and another for the other stakeholders with interfaces between them. Companies such as Oracle (with Clinical One) together with Medable offer this. With ongoing development between them and other platform companies, it seems unlikely that this will persist for long as using two platforms is still sub-optimal.
We also see more companies start from a platform base, but deviate through the either acquisition of 3rd party systems OR the development of new products that they separate from the core platform. They may be in a position to interface these technologies well, but in reality they are not a single platform, and they therefore lose many of the benefits.
So — here are 5 levels that can be used to measure a ‘platform’.
Level 1 — Simple Sign On
When I use my iPhone, I look at the screen, it logs me in. That is what I expect. If I am a patient in a clinical trial, I expect the same simplicity.
For other stakeholders, I want a single username and password (probably with Multi-Factor-Authentication — MFA for security). For a clinical trial platform to achieve this, it must support a single login that works across sponsors, trials and modules. Typically, this is not achieved because either the products are disconnected, the platform does not support it, or sponsors operate as if their users (including sites) are not involved in any other clinical trial.
Level 2 — Common User Experience
User experiences on a platform’s components should be familiar and efficient. If I am trained in one area, that training should apply to the rest of the platform. In eClinical, that might be CTMS, eTMF, RTSM, EDC, eCOA and beyond. The only time a user experience should be different is because a use case is sufficiently different — for example, the entry of data into an eCRF or an ePRO has different demands than uploading documents into an eTMF module.
User experience goes beyond a look and feel and applies directly to system integration. This is best demonstrated with EDC and RTSM products. There is no value in site staff leaving an EDC system to enter data into a RTSM solution just to screen and randomize a patient when this can just as well be done within the EDC system. This is a limitation for the site. Oracle have figured this out.
User experience also extends to task management. If I start work in the morning, I want a single list of things I have to do. I don’t want to go to multiple systems, dashboards and reports that display read-only information from different products. I want a single list that allows me to sort, prioritise and take action from one place.
Level 3 — Data Sharing and Referencing Model
If I have a patient in a clinical trial, the platform should hold the data of that one patient. Not multiple copies of that singular patient. This applies to the patient and all their data. The data may be manifested in different areas of the product, but that should not necessitate copying that data.
Vendors often feel that this approach is too restrictive and that each module should be standalone. The idea is that a vendor can sell and support modules independently. In my humble opinion, that demonstrates a lack of understanding of modern cloud technologies and methods. The two approaches are not exclusive; you can have a single instance of data and still have multiple modules working efficiently with that data. This is especially true when working with highly scalable cloud native computing tools.
In eClinical, the variance of the metadata structures , in places, makes the principles of replication between different modules difficult. This in part, is why eClinical systems today exist in silos and define their own data.
The only time that I feel it is merited to create a copy of the data is when creating snapshots where the structure may be new, the delivery of the data needs to go to an external destination, or the data must manifest for a single point in time. This is likely to support BioStats or archiving.
The existence of the data is one thing, but this needs to extend to the ability reference the data across the platform. An eCRF form should be able to read a Prescreening form or eConsent form for the same patient. The workflow engine should be able to reference any data across the patient lifecycle — at least in the patient workflow context.
Level 4 — One metadata repository
This is getting a bit technical, but bear with me here. Configured cloud systems are driven by their configuration and their metadata. Metadata is data that describes other data. Metadata might describe that a date of consent is a date field. That it stored in the DISPOSITION domain and it is captured on either the eConsent form or the screening form. It might also say that only a single instance of it exists for each version of the consent per patient. This information not only defines the field itself, but the labels, the representation in a table and zero or more representations on screens or listings.
A MetaData Repository (MDR) is a centralized store for metadata and is the key to an effective platform. It is the single point of reference — source of truth — for information about the data that is used across the platform and beyond. A MDR as part of a clinical research platform should hold 3 things:
1. Data Definitions,
2. Forms/Lists (representations of data,) and
3. Workflow (the processes that are followed for the data).
I should stress that the development of a comprehensive MDR Editor that meets all stakeholder demands for all target functional areas is by far the most challenging undertaking in eClinical systems development today.
The MDR sits side by side the Data Repository. A comprehensive data repository relies on the context provided by the MetaData Repository.
On a side note, I was recently asked which department ‘owned’ the MDR. The answer to that question is Clinical Research in general, not Data Management, BioStats, or any single department as they have existed in the past. Metadata defines data about data for the entire lifecycle of the clinical research for all stakeholders. Many departments contribute and many departments benefit from the MDR.
Level 5 — Process Automation
Assuming the MDR supports the delivery of workflow definitions, workflow is the secret sauce that defines the automation of flows along the clinical trial lifecycle. Understanding the inter-relationships between the different activities that take place in a clinical trial is typically the light bulb moment for platform evangelists. When working with a point solution — nobody cares. You can get away with hard coded logic. When you open things up to multiple stakeholders with multiple connected modules, it starts to make sense. If you open things up further to the patient it goes from a nice to have to being a fundamentally critical aspect of the platform
Current Landscape
In the future, I aim to attempt to place each major vendor on a platform maturity scale diagram. This may be controversial, as we have some vendors claiming to have a unified platform, but do not, or, that have started with a platform but deviated with some of their products. However, it is key for the future evolution of technology in clinical research that a true reflection of the platform integrity of each vendor is transparent to consumers. No vendor on the marketing today (that I am aware of) has a platform for all functional areas at Level 5 though some are claiming to be on track towards this.
PostScript
Some readers will be aware that I was responsible for the development of the Clinpal DCT platform from 2012 until 2019. I should make clear that although Clinpal development manifested many of the aspects of ‘platform’ that I identify above, the development also taught us lessons on what is necessary for the future. So, recommendations above reflect 80% of what I have done and 20% of what I should have done. I will leave the reader to guess the 20%.
I welcome any challenges or suggestions to information shared in this article.
In my next article, I will next revert to the earlier question on whether EDC is an appropriate base for a Decentralized Clinical Trial platform.
- This blog was originally published on LinkedIn by Doug Bain on February 11, 2022*
About KCR:
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.
