ARTICLE 4- How to choose your Medtech EDC System
In the fourth of our series of articles on Managing Data and eClinical solutions for Medical Device Companies, the CRFWEB team discuss the critical actions and processes that will ensure that the Medtech EDC system (and vendor) you choose will fully meet your needs.
We’ll explain WHY you will most likely need to work with an EDC vendor by looking at the potential pitfalls of the shareware approach.
We’ll look at WHAT an EDC company actually does – and what it does NOT do – and how that should set your expectations in terms of input at the design phase.
We’ll explore WHEN you should procure your system and HOW to engage with vendors to ensure your best outcome.
We’ll identify WHO the key stakeholders to consult are when procuring your system and what their needs are.
We’ll address pricing in more depth in the following article but here we’ll look at the central importance of the need to clearly identify and factor in unstintingly the level of professional services, support and training you’ll need to ensure you can deliver on time and on budget.
Before you start choosing your Medtech EDC System
Before you even begin the process of selecting your Medtech EDC system, it will save you a good deal of time and money if you can first be sure that you have clear answers to the following questions:
- HOW do we determine if we need a commercial EDC system?
- WHAT does an EDC vendor do?
- Do we have a clear expectation about HOW the key activities, roles and responsibilities in the development and delivery of a study or investigation will be shared between the sponsor, CRO (if used) and the EDC vendor?
- WHEN should we procure an EDC system?
First things first – do we even NEED an EDC vendor?
There are several no-cost/low-cost EDC shareware platforms available, so this is a reasonable question to ask. Whilst these platforms offer much of the very basic functionality most studies or investigations require, you will almost certainly need to modify such platforms extensively to meet your specific requirements. Shareware platforms tend to lack the levels of configurability of more complex commercial systems and not only that there is the added difficulty that an additional software development required can be tricky. The money saved on licenses by going down the shareware route will be swallowed up by the increased cost of services and software development needed to build the system you need. A vendor will not only be able to offer you clear and transparent pricing for these activities, testing and validation will be undertaken as part of a well-defined and well understood process. Unless your trial or investigation is small in scale and relatively simple, it will generally pay to partner with a commercial vendor who can help you quickly and efficiently with configuration, development, testing and validation.
What does an EDC vendor DO?
It’s important to understand that a company that sells an EDC system – or a full-eClinical platform for that matter – is NOT a clinical research consultancy. Their purpose is to sell you a system and a set of services that fits closely with your needs. If you are hoping that the company will provide a major input into helping you scope out your requirements for your proposed study or investigation, you will either be rapidly and rightly disabused of this expectation or, in the worst- case scenario, end up paying a lot of money for the wrong thing. So, before you start talking to vendors, you must have a clear understanding of the type and scale of investigation you need to undertake to either gain or retain market access. If you don’t have the in-house knowledge to get to this base-camp position, you’ll need to bring in expertise in the form of CTM consultancy or work with a CRO. What you mustn’t do is assume that a vendor will sort this out for you as part of the sales process, and/or post sales support. An EDC company will certainly help you configure the system so that it accurately meets your requirements – they will help you BUILD your system, what they WON’T do is DESIGN the system you need. Sometimes, the build phase will require bespoke software development as well as high-grade expert system configuration. It’s really important that you confirm this requirement and check the vendor’s capabilities in this area.
Understanding the designation of key activities, roles and responsibilities
The type of vendor that will best suit your needs will be determined by what your expectations will be in terms of services as much as the functionality offered by their system. The greater the clinical trial/study management capacity/expertise and technical capability that you have at your disposal – either in-house or via your CRO partner – the less you will need to rely upon your EDC partner for configuration and support services. The more you expect to be able to deliver yourselves (or via your CRO) the wider you will be able to caste your net when selecting your EDC vendor. Conversely, the more you expect from the vendor, the more closely you will have to scrutinise their claims concerning their build and support capabilities – not only in terms of quality and cost, but in terms of timescales for delivery. This is an area where there are significant variances between vendors.
WHEN should we procure an EDC system?
It’s not uncommon for us to receive enquiries from companies that have yet to develop a clear understanding of the above issues, still less any coherent plans. This is way TOO EARLY to start the laborious process of kicking tyres. We’d go further, it is only really worth talking to vendors once you can put together a detailed Request for Information, and we discuss what this document needs to cover off in the following sections.
Despite our emphasis on having an in depth understanding of your needs before beginning to engage with vendors, it’s quite possible to be TOO LATE, also. In the past we’ve occasionally received enquiries from companies that have already designed their CRFs and engaged with ethics committees and competent authorities before deciding how to deliver their project via EDC. No data management plan or data validation plan had been put in place which meant costly and time-consuming delays whilst the eCRFs were designed, tested, validated, modified as required and submitted to the authorities for sign-off. Ideally, a vendor needs to have been selected after the protocol has been designed so that data management and validation plans are part of the submission to the authorities.
Engaging with Vendors
The EDC marketplace is as large as it is diverse. Capterra has some 201 products listed as EDC systems and 175 systems listed as Clinical Trial Management Systems – many, naturally, appear in both categories.
The available range of features and functionality is very broad, too. At the upper end are powerful end-to-end, full-service eClinical platforms built to meet the needs of complex, large scale multi-year, multi-site clinical trials for the pharmaceutical industry. At the lower end, more straightforward EDC systems primarily designed to support electronic clinical outcomes assessments (eCOA) with fully compliant eConsent capabilities and additional patient-centred functionality such as eDiaries. It’s important to note that being at the lower end of this complexity range does not mean there is a lack of sophistication or a robust capacity to scale.
At which point it best to pause, breathe and ask probably the most important question that needs to be asked on the path to successfully selecting an EDC…
What, exactly, are we trying to do?
Mapping your needs to functionality
It’s fair to say that most if not all EDC systems will share core class functionality, which SHOULD meet these universal needs, but it does no harm at all to check!
How important is an integrated approach to your study? It’s worth deciding at the outset whether features such as integrated ePRO, IVRS or coding tools are vital to the protocol’s success. The additional costs involved may be well spent when compared to the cost and time spent on more manual reconciliations.
However, most systems will have been designed to be optimal for specific types of investigations or clinical trials. For example, some systems will have been designed with the needs of pre-approval clinical trials prioritized, whilst others are designed primarily for post-marketing surveillance or research. Still other systems, known as Registries, are configured for longer-lasting data gathering projects – where there is a need to track symptom development over time related to specific diagnoses, for example.
So, it makes sense to focus your search on the subset of systems that have been developed with your class of investigation in mind. Easy to say, harder to do. Before you begin window shopping then, it’s important to determine as far as possible what it is you intend to do and what the critical parameters of your study will be and make sure you can supply vendors with a very clear statement of requirements. Specifically, you need to determine and record clearly:
- Study type
- Therapeutic Area
- Duration and key timelines such as expected time to FPFV, Database Lock
- Number of Patients
- Number of Sites
- Countries
- Number of Visits
With this information clearly delineated it should be relatively straightforward to identify a minimum viable set of features and functions required to deliver the project. It’s worth spending time and money on this stage – mapping your need to features and functionality accurately and realistically will save you a lot more time and money downstream. This information will form the core of a Request for Information (RFI) that will be sent to a range of vendors – but there will be more to add to this before it’s good to go. Specifically, you’ll need to know more about the services they offer – and that these are aligned with your expected requirements and last, but not least, what the pricing options are.
With a strong understanding of what your baseline system requirements are, it will also be far easier to avoid excessive spending on non-essential functionality or overly complex systems that deliver more than you need. Higher system cost can also be further exacerbated by need to invest more in training to ensure the system is used correctly. A mismatch between system and requirements can even lead to project failure, in a worst-case scenario.
Universal user needs
All trials are different, yet they share many similar underlying needs, irrespective of the actual study or investigation. These are:
Clinical Sites: user friendliness is key. Time is usually pressing, and staff will always have many competing priorities. The harder it is to enter the relevant data, the more likely errors are made, but just as importantly, the more likely delays are simply due to staff getting behind schedule.
Subjects/Patients. The likely capacity of patients or subjects can also be a major factor when choosing your system. The expected modal age, dexterity and familiarity with technology of the study cohort may well severely constrain the complexity of the any system under consideration. This is especially relevant if ePRO or eDiaries are being considered.
The Clinical Data Manager: user friendliness, too, of course, and a system that all users – including site monitors – can be trained on easily and rapidly. They will also want a system with high quality, easy to generate standard reports as well as the tools to easily customise reporting. Finally, the CDM will also need to be able manage system changes with a minimum of fuss whilst retaining the integrity of prior versions.
The Clinical Project Manager (CPM) and the Site Monitors (CRA)s: both are key players who will have different – and sometime conflicting – views on what constitutes an optimal EDC platform. The CPM is looking for useful reports and analytics to support risk management and project management. The CRA is looking at reports to help manage sites, and the task of SDV.
Statisticians will need high quality reporting with data extracts available easily and in the formats required. They will also need to be able to understand easily how any protocol change impacts on data extracts.
So, it will only save money and time if you can canvass these stakeholders for their opinions when putting together your RFI.
Vendor Services
So, having established what the software needs to deliver, surely this is the time to think about pricing? No. You first need to be sure that the vendor can deliver on critical professional services. It’s too easy to think that services are just a way for a vendor to inflate the bottom line, and let’s just get to a price first and ask those questions later. The reality is that if there is a mismatch between the services you need and the service levels you have paid for, the project may well cost you far more than expected downstream or could even fail. Scoping out what services you are likely to need – in terms of configuration, training and support is every bit as important as understanding the system functionality you will require.
What role will your vendor play in system configuration?
In terms of services, the first critical issue to resolve is the level of participation you are expecting from the vendor in configuring the system to meet the needs of your project. It may be that your company has the requisite in-house technical expertise – or the CRO you may be partnering with has – to do this. Alternatively, you may be expecting most of this work to be done by the vendor. Equally, it’s quite possible that at this stage you have yet to determine how this key element of the overall project will be delivered. Therefore, the RFI needs to ask questions of the vendor about how they support system configuration and to set-out indicative costing structures/plans for:
- CRF configuration
- CRF testing and validation
- Modifications and adjustments
If the vendor is expected to play a significant role in system configuration, then it goes without saying that they will need to be able to demonstrate an in-depth understanding of all the key standards and requirements of the industry (GCDMP, GDPR, FDA 21 CFR Part 11) and, just as importantly, that they can deliver on the regulatory documentation requirements. At the RFI stage you probably would want to simply ask the vendor to evidence their capabilities but later, when you are closer to making the final choice, you’d need to be asking for references or ensure that a compliance/documentation expert has an opportunity to deep dive into the vendor capabilities with their technical people.
Timelines are also important – you also need to feel confident that your vendor can deliver the configuration capabilities you require within your allotted timeframe.
Training
Nowadays training is mostly delivered online via videos, interactive webinars and online learning packages. Systems have evolved over time to become far more user-friendly (generally, at least) but it makes sense to ensure that all your key operational stakeholders are fully trained from the outset to ensure that the project runs smoothly. Learning as you go is all very well, but it increases the chance that errors will be made which will lead to rework, delays and consequently additional unnecessary expenditure. Make sure your RFI asks for information about training delivery and indicative costs for:
- Subjects/Patients (when ePRO is planned)
- Clinical site users
- Clinical Trial Manager/Project Manager
- Site Monitors/CRAs
- Data Managers
- Statisticians
Support
What level of support are you going to need from your Vendor? For your RFI, you will need to scope out in general terms what Service Level Agreements you are likely to need. At this stage it doesn’t have to be too detailed, but you should have an idea of the basics, e.g.:
- Will you require multi-lingual site support?
- Will you require 24/7 support?
- What sort of time to resolution for customer queries are you likely to be happy with?
- What sort of time to implementation are you likely to be happy with for protocol changes?
- Will you (or your CRO) staff provide frontline support to sites, or the vendor?
At this stage, what you want to really need to know is: does vendor capacity align with your needs and what are the charging options?
It never pays to scrimp on the services. Having a clear understanding of your service needs and a clear understanding that a vendor can deliver is fundamental to the success of any project. Once you have decided what your system needs to achieve on a technical basis, it’s likely that the service offering will be every bit as important as price when it comes to making the final choice.
Pricing
Last, but by no means least. It’s completely natural to consider the headline cost first, but cost of what exactly? Go to any vendor website and unsurprisingly you’ll find little or no useful information about what it will cost you. That’s because the scoping exercise in terms of functionality and service needs will deliver a unique matrix of requirements. No two studies will be the same and similarly no two companies will have the same capabilities; some will require very minimal services from a vendor whilst others will be hugely dependent. Most vendors will be flexible and will provide bespoke packages depending on your both your functional and service needs, which is why it’s important to be clear about these at the outset.
There are many different pricing models available, with Licensing, Subscriptions, Pay as You Go and Pay per Protocol all widely used. Again, there will be no easy or obvious answer as to which model you should choose as the devil is always in the detail. The questions will always be: “What does that include?” Very often, the best price option turns out to be the most expensive when all the optional extras that you’ll almost certainly need are priced in. Caveat Emptor!
We’ll attempt to unpick this very tangled and thorny issue in an upcoming article.
Vendor Health Check
It shouldn’t need to be said, in a way, but it’s always worth just double checking that the company you are dealing with is robust and in good health. This, after all, could be the start of an important long-term relationship and so you need to be as sure as you can that they will stay the course. The tools available to do that will vary from country to country, but you might consider asking for access to filed accounts, for example, if you are close to making the call.
Summary
- Understand clearly what a Medtech EDC System vendor does – and if you need one
- Understand what you (and/or your CRO) will deliver in terms of study/investigation build, modification, and support – and how that defines your EDC vendor expectations
- Understand when you need to engage with vendors
- Make sure that you have spent as much time as you need to develop an accurate and meaningful Request for Information (RFI) document to be sent to vendors that:
- Defines your functional needs
- Defines your service needs
- When viewing system demos, make sure that the vendor is using your functional needs as the basis of the demonstration – its up to them to demonstrate that they can deliver what you need. Have your experts on hand – or those of your CRO – to ensure that required functionality is covered off, point by point. Make sure you have clarity over what is part of the standard system and what might require development.
- Ask for access to a test environment and perform testing as a formal project in collaboration with your vendor.
- Ask for references so that you can explore service capabilities with existing customers.
- Set up meetings with vendor staff to deep dive into service capabilities.
- Ensure that any final quotation is fully itemised (functionality and services) in line with your needs as fully detailed in your final Request for Quotation (RFQ)
- Health check your potential vendor
Youe Medtech EDC System: looking to the future
We are still living in a world where clinical safety and efficacy data is gathered via largely discrete, well-defined activities – trials and investigations. However, we are beginning to get a sense of what the world might look like in years to come. MDR has rightly focussed on the centrality of ongoing post-market surveillance as fundamental to ensuring the safety and efficacy of medical devices and this reflects a similar change of perspective in pharma/biotech. In the medium to longer term, the low cost and easy of availability of genomic data combined with access to anonymised EHRs, overlays of lifestyle data from a vast array of commercial sources will allow meddev and pharma/biotech to develop unprecedently granular and detailed insights into how, when, where and for whom their products have the most significant positive impact and where there are concerns about safety and efficacy. The capability to interface with this universe of Big Health Data will be a fundamental design requirement of all clinical products and supporting services in the future. Essentially the tools are already widely available to take advantage of this vision, the bottlenecks are data ownership and privacy issues but also more fundamentally, data processing capacity. Whilst the issues of ownership and privacy will remain contested for years to come, it’s likely that society will be increasingly relaxed about them if health benefits can be demonstrated. Processing capacity is, in the short term, a significant hurdle but, in the medium term, the promise of quantum computing will easily overcome these challenges.
EDC vendors will evolve into long term partners with meddev or pharma/biotech companies to provide continuous, real-time highly granular information that will not only ensure ongoing product safety, efficacy and concomitant market access but also offer unprecedented opportunities to rapidly identify how products can evolve in form, function and purpose.
How CRFWEB can help you
Many companies will need to re-engineer core business processes such as QMS, Risk Management and Documentation in order to be fully MDR-compliant. There will never be a better time to bite the bullet and migrate to an integrated Medtch EDC system for all future clinical investigations as part of this systems overhaul.
Optimised for the Med Tech sector, CRFWEB will help your company capture data from trials more easily, efficiently and cost effectively. Of course, many in the EDC and wider eClinical sector can make similar claims, but we are confident that CRFWEB delivers all the key functionality you need in an agile and simple to use package…at a fraction of the cost of the big industry names.
