HOW TO TURN A PROBLEM INTO AN OPPORTUNITY
Have you ever asked yourself how you could change your inadequate and by now obsolete legacy EDC system for a new one?
Have you ever had the feeling of being trapped into a mature but experienced any of the following issues while dealing with your eCRF provider: rare software improvements, lack of support or – even worse – an expensive upgrade or a system discontinuation?
We’d like to present you with some of the assessment criteria, based on our experience of migrations. We support these criteria with the outcomes of feasibility studies, client negotiations, actual migrations and post migration feedback from Pharmaceutical companies and CROs.
To start with, the technical and economic evaluation of migrating your eCRF/EDC platform is fed by multiple real-life issues and certainly not just because of the desire for modernization or an upgrade, and even not because of simple cost-driven analysis.
A mixture of disadvantages due to legacy systems can easily become a tremendously disturbing factor, especially during oncological studies, which may last from many years up to a decade. We’re well aware that sponsors and CROs don’t welcome the idea of upgrading the EDC application in the middle of a study. Even when the upgrade implies major modernizations and a positive user-impact, or it speeds up delivery time, hence providing faster results.
Even though the motivation to migrate to another EDC platform arises out of pure necessity, at some point decisions will have to be taken. If it’s time for you to take action, we advise you to connect with an expert party willing to guide and support you with its wealth of experience dealing with any type of study, negotiations, migration sand most importantly, a proven track-record.
DRIVERS OF CHANGE – WHEN SHOULD YOU CONSIDER TO MIGRATE?
If even one of the factors mentioned below applies to your organization, then in our experience
you may consider a migration of your EDC system.
- Out-of-balance total costs – is the global investment on licenses, infrastructure and human resources in line with your revenue?
- Additional overhead costs – required to keep the EDC system up and running – IT resources, specific, exclusive and therefore expensive professional expertise.
- Local infrastructure costs – the maintenance and support of your on-premise solution has become too expensive (especially in comparison to cloud-based solutions).
- You are using an obsolescent system – this leads to a spiral of negative factors: regular costs remain high, upgrades are imposed and expensive, the internal organization is burnered, find ing resources to fix things can be challenging. Vendor support becomes limited or disappears all together and therefore it may become a serious risk to the stability of your study.
- Absolute obsolescence – failing performance, incompatibility, the need to impose obsolete requirements on the clinical centers; for example, unsupported versions of browsers or Windows, or cumbersome technical requirements.
- Inflexibility – some things that are obvious to us may not be obvious at all within legacy systems. For example: it is not natural that a query submitted by the Investigator will be instantly visible by the Monitor. It is also not certain that laboratory changes, new diagnostic kits/new ranges will be managed dynamically. Protocol amendments are often approved by the centers at different times and perhaps your EDC cannot cope with different versions of the same eCRF being concurrently inuse at different centers.
- Compliance deficit – even a successful study can turn into trouble and deliver non-budgeted costs. For example, in consequence of two main drivers we migrated a non-profit study: positive outcomes were reached, and the study needed to be expanded into North America, where demands on compliance from the new collaborators raised.
- Unsatisfactory data quality – it may happen that an EDC system will show its limits after some time. For example, when data quality starts to be evaluated by all stakeholders in the process (internal data managers; sponsor’s data manager or statistician.) A typical example is an EDC platform which is totally focused on collecting data and poorly focused on monitors’ activities or it is lacking data management tools.
- Limited ability to expand the platform’s scope – this is the case of an EDC system that, for instance, isn’t ready to embed an ePRO or any other new module.
- Adding all up, how does this affect your clinical operations?
- Does it slow you down?
- Does this weigh on your budget? Does it force you to make unforeseen investments?
- Does this bother and burden your teams?
- Does this, in the worst case, affect the compliance of clinical centers?
- Does this limit your business development?
RESISTANCE TO CHANGE
Let’s focus on a complex case
A CRO is considering the migration to a new platform and has many active studies on a legacy system, and a three-year licensing plan at flat fees. The objections to change are likely to develop from two main reasons:
- additional costs for the newly selected provider;
- the company would find itself managing two separate systems at the same time for several years.
Let’s simulate a comparison between the basic licensing costs of a legacy system (on-premise formula with a three-year flat fee up to a limited threshold of users), and a new provider (cloud-based SaaS at a monthly fee per project). Both solutions cover the same EDC and Data Management process.
LEGACY ON PREMISE flat fee – three-year subscription (Pay-than-use)
|Total flat fees
||2020 – 2025
|SVR & System Management IT Human Resources System Validation Package Mandatory upgrades
2020 – 2025
To be calculated
PAY PER USE, at monthly fees, including 3 study migrations
|Total flat fees (legacy) + new provider (pay per use per project)
||2020 – 2025
|SVR & System Management – IT Human Resources
System Validation Package – Mandatory upgrades
|2020 – 2022 only
||To be calculated
It is possible for CROs who rely on a wide studies pipeline, to benefit from flat license fees. In such cases, when it occurs that comparing the basic licensing is merely in favor of the legacy (on-premise) system, we urge you to keep in mind some of the other costs that are related to the legacy system:
- IT infrastructure, System management, System validation (within a cloud-based application these are all responsibilities of the provider).
- Internal effort throughout the eCRF configuration, monitoring and data management cycle.
- During such long-term collaborations you’ll face expensive licensing upgrades.
For pharmaceutical companies who insource their data management and for mid-range CROs with a limited number of live studies, we are convinced that a migration will deliver a more then average quick return-on-investment.
Once all boundaries have been cleared, all that remains is to compile a set of guidelines to help you choose your new business partner for EDC and Data Management.
HOW NUBILARIA CAN HELP YOU
In this paragraph, we’re now going to review a number of strategies which, based on our customers’ experience, might help you prioritize your business requirements, thus leading you to make business-sound decisions.
- Isolate poorly supported systems. CROs frequently use multiple systems simultaneously. We strongly advise to abandon the most problematic ones throughout the entire chain and try to make these systems converge to a more recent one.
- Prefer validated and secured cloud-based systems over on-premise solutions. The general industry (B2C & B2B) is nowadays driven on cloud-based solutions. There is no exception for EDC and eCRF anymore. The advantages simply overwhelm the disadvantages, regardless of which point of view one takes.
- Select an EDC business partner with valid experience in clinical studies & migrations. Migrating is not simply a matter of a correct database match and historic data recovery, but it requires a 360° migration strategy. Key factors of your choice might include:
- specular eCRF vs. optimizations / enhancements
- Data Handling Plan review
- Data Cleaning objectives.
- Adopt a time-inverse strategy. Take a study that will end later and migrate this one at first. Then the second-in-line, and so on. This way you’ll really anticipate the overall end-of-life of your critical legacy system (this approach has also the benefit of cutting costs dramatically).
- Pick the right time frame. Any discontinuation offers you a chance! Whether it is a protocol amendment, an extension of collaborating centers, or the closure of uncooperative centers, an intensive data cleaning or data review intervention; the need for users to face change generally matches well with a platform refreshment and a ‘re-launch’ of the study.
- Demand clinical data management from the new vendor or be sure that the new application will be able to process fully functional data management services. You don’t want to see ‘fast to collect’ and “slow to clean/close” studies anymore.
- Demand full mobile support from your new provider. Of course, nobody will fill out an entire eCRF on a mobile phone, but EDC is more than just data entry. Many other stakeholders, like project managers, sponsors, and even monitors will gain advantage from systems that expand to mobile service.
- Demand for a solution that includes ePRO (electronic Patient Reporting Outcome).
- Consider transparent pay-per-use costs, aligned to your business (realize that the more projects you won, the more you pay for the service).
MIGRATION STRATEGY AND EXECUTION
What remains to be assessed is the reliability and transparent track-record on migrations of the selected partner. Here below the typical project plan managed by Nubilaria, in 5 weeks.
W0 – Migration Start
Collection of eCRF datasets and eCRF metadata from Legacy System
W1 – Raw import
Datasets & Metadata imported 1:1 into new provider’s database. Zero information loss!
W2 – Format Conversion
Datasets & Metadata converted to new provider’s eCRF format
W3 – User Acceptance Test
An UAT is performed by customer
W4 – Platform Switch
Legacy System turned-off, new provider’s turned-on
W5 – Cleaning
1st cleaning checks performed directly in the new provider’s system
W0 – Data collection and preparation
Datasets: which sources need to be prepared?
- All the clinical datasets
- All the audit trail datasets
- All the e-queries and data clarification datasets
- All the metadata (layout, logic and validation)
- All the provisional and retrospective checks
- All the relevant study documentation
- All the appropriate study contacts
- All the existing processes and their own timelines and deliverables
The provider is responsible for:
- Collecting and storing the complete set of study information safely and in the native format
- Attending our training with personnel whom are qualified in the use of the legacy system
W0 – Validation
At stage W0, at the very beginning of the whole process, we have the first crucial point: the copy of the legacy datasets from the legacy infrastructure into the new one. This copy must be an exact copy of the legacy data and it will represent the ‘real’ SOURCE DATABASE since it would be too complex and cumbersome using the legacy system as SOURCE during the transcode phase (translation into the new architecture/platform). Such cruciality requires an accompanying validation step (described in the table above).
W1 – Data import ratio 1:1 into the new platform
Import ratio 1:1 (For example: AS-IS) of all applicable legacy information, including:
- All clinical datasets
- All e-queries and data clarification datasets
- All metadata (to replicate – as close as possible – an exact copy of the previous system’s layout as well as its look & feel)
- All the provisional and retrospective checks? (to be analyzed)
The provider is responsible for:
- Importing all applicable legacy information seamlessly into the relational database
- Checking the integrity and exhaustivity of the import process
- Assuring that the legacy information is converted into the new data store format (relational database) from the very beginning of the process
- Assuring that no legacy information will be left behind
Sometimes, the legacy audit trail is not converted into the new format. This may occur when the two formats are so complex that the conversion does not outweigh the cost. In that case, the legacy Audit Trail will be stored for inspection, both in the native format and in the XML format of the same dataset.
W2 – Datasets & Metadata converted to new format
Adapt, translate & convert the legacy data to the new database & the new CRF:
- Build empty eCRF structure; the challenge is to be as close as possible to the original version in terms of layout and look & feel
- Fill in the new eCRF with patients’ data together with data clarification history
- Build provisional checks
The provider is responsible for:
- Analyzing the eCRF structure and preparing an empty copy of the eCRF with the new platform’ standards
- Filling the new eCRF with all the patients’ data and data clarifications
- Setting up provisional checks, based on the existing data management plan
W2 – Validation
At stage W2 the actual migration will take place. This means that each dataset copied into the new vendors infrastructure in phase W0 is then translated and adapted to the new platform data model without losing information. Thus, W2 represents the crucial phase and it has to be validated (as described in the table above).
W3 – User Acceptance Test
After the new platform is completed, it is time to test the system together with the client. The following test areas undergo the testing phase:
- eCRF structure (visits, sections, fields)
- Edit checks
- Patient imported data, including related clarifications
- User profiles
- Data entry of dummy patients
- Complete the migration of patient data
The provider is responsible for:
- Preparing a fully functional pre-production environment, filled with patient data
- Preparing a comprehensive test plan
- Assuring that also the living eCRF processes have been designed correctly
This is the crucial testing phase and it requires full commitment by all involved parties.
W4 – Go Live
- Get the latest database snapshot from the legacy system
- Inform the users (as soon as possible!)
- Shut down the legacy system
- Start the migration process with up-to-date data
- End the migration process and give GO/NOGO feedback
- If GO, then turn on the new platform and send passwords to the users
- If NOGO, notify the client and start up the legacy system again
The provider is responsible to:
- Start and complete the migration process in a timely manner
- Give GO/NOGO feedback
- Send passwords to the users in case of GO
- Advice the client in case of NOGO
W5 – First retrospective cleaning run
Post GOLIVE activities:
- Implement all the offline consistency checks
- Optimize the new process vs the same legacy process
- Schedule the first run
- Monitor the results before emitting data clarifications
The provider is responsible for:
- Implementing and fine-tuning retrospective checks
- Analyzing the process of the previous provider in order to optimize this data management process up to the end of the trial
- Setting up an agreement with the client for an appropriate Data Handling Plan (DHP)
Running a retrospective cleaning on a regular basis (in accordance with the client)
In our experience EDC migration is not a rare issue but an unavoidable development. This is related to these main factors:
- Clinical studies have multi-year life cycles
- This implies long term collaborations with the eCRF Provider or technologic partner
Conversely, the developments in business and technology have a faster pace.
Whatever the reasons that lead to migrate one or more studies, Nubilaria ACTide is the safer, more reliable solution as the new platform for your studies.
And this for several reasons:
- Migrating to the ACTide platform is a painless procedure either for the sponsor, the clinical operations and investigators because of:
- a consolidated method without data loss for database transfers (data history and audit trail)
- our commitment to rebuild the former user interface without disruption
- a tested operational plan with well-defined milestones
- almost no downtime requested if the weekend option is chosen
- freedom to choose between an “AS IS” migration strategy and an improvement strategy
- full responsibility and consultancy on Data Management Plan and Data Validation Procedures (engagement for all the studies running or limited time frame in order to fix all issues about legacy’s validation).
- In our experience the pure cost of a migration turns out to be significantly lower than the obtained benefits:
- Improved user acceptance
- Move from an ‘on premise’ to a ‘cloud based’ approach and from a pay then use to a pay per use formula: the ACTide fee grows as long as your revenues grow so the grow ratio is linked with the actual service base used.
- Fully functional data management services: you don’t want to see ‘fast to collect’ and “slow to clean/close” studies anymore.
- Freedom to go with a self-provisioning approach for design, configuration, validation and data management (thus reducing the service fee).
- Possible increase in flexibility due to a more modern system: opt for mobile integration, ePRO… That means business needs readiness.
- This is our point of view about migration processes.
- What is your experience in migration?
- Do you find yourself in these issues?
- Do you think we can help you solve them? Is your experience different?
We would like to get in touch with you. Let’s turn this problem into a new business opportunity, together!
The Nubilaria Team