Clinical research sites that are in the process of investigating clinical trial management system (CTMS) adoption are finding that the site CTMS space is in flux with mergers, discontinued products, and new start-ups looking to drive innovation. It can be challenging to focus on what’s important to each individual site as they evaluate the available options.

We listen to many research sites as they work through the process of evaluating CTMS features and benefits, driving the decision toward or away from CTMS providers in the process. The two questions we hear most often are:

• What will happen with our existing data? and
• Can you integrate with other applications used at our site?

We sat down with Harry Chahal, the vice president of professional services at WCG Velos, to address these questions. Since its founding in 1996, Velos has supported dozens of data migrations and completed more than 100 third party system interfaces for its CTMS clients.

Cerdi Beltre: Velos has seen first-hand the changing landscape of site needs in the past two decades. What are the most pressing integration concerns research sites have now? How have they evolved?

Harry Chahal: In the past two decades, clinical trials have become far more complex. Sites have  to collect more data points and billing compliance is more challenging. Electronic medical records (EMRs) have changed over the years as well, with EMR interfaces and financial management gaining in priority. Also, off-site or cloud application hosting has become especially popular, as it is considerably more efficient, however it adds new IT security concerns.

CTMS platforms used to be standalone solutions – twenty years ago most research sites didn’t have EMRs to interface with. Now, integration is essential, and extends to multiple systems beyond just EMR. While we are seeing these requests for integrations across all research site types, from small independents to larger site networks, this is especially true for large research institutions that have the clinical trial volume to fully justify the investment into integration.

Cerdi Beltre: When research sites switch from one CTMS to another, what are the typical reasons for making the switch?

Harry Chahal: In my experience, the drivers to switch CTMS systems are inadequate capabilities or configurability, and research billing compliance risk. Sites typically want to reduce the number of systems needed to get the desired results. They also want a system that is easy to navigate and reduces the research staff’s workload, which integration helps to achieve. For example, sites want to only enter data once into the CTMS and have it feed directly to the EMR and/or have IRB-related items interface with the CTMS.

Cerdi Beltre: ​What happens to existing data? How important should this factor into the CTMS choice?

Harry Chahal: In our experience, most clinical trial data can be migrated and it’s an important step to avoid any interruption in workflow. Some data may not need to be migrated. For example, it may not be worth the effort to migrate data for studies that are closing soon or are closed. It also depends on how complex their legacy system was and what functions the site was using. As such, the data migration needs of each site vary, however, most sites benefit from some level of data migration and it’s an important factor in the decision-making process. Sites must review what the new system offers compared to where their data was previously and evaluate whether anything from their old system can be discarded, or how they can revise their processes to best utilize the new CTMS.

Data migration should to be quick, seamless, and accurate. Minimizing workflow disruption is paramount for sites that are using a system on a daily basis. Once the data is migrated, either the site or the new CTMS team needs to verify the validity of the migrated data.

Cerdi Beltre: ​What challenges do you typically see when migrating data from one CTMS to another, and how do you handle these challenges?

Harry Chahal: We usually see one-on-one matching of fields and definitions across different CTMS portals. The challenges tend to be around code list values, picklists, data format, data integrity, and data validations such as mandatory data fields. These are semantics challenges.

There are several different ways to handle the validation of the migration:

1. Sample data validation: This involves the random selection of records from the legacy system and comparing them with the target system. Sampling is not a foolproof system as it selects random records, so we’ll often use or recommend use of profiling techniques that result in better data coverage versus purely random sampling.
2. Subset of data validation: Instead of choosing random sample records for verification between the legacy and target systems, here we choose a subset of records based on row numbers such as the first thousand records or ten thousand records. The advantage with this process lies in selecting more records resulting in more data coverage.
3. Complete data set validation: This is the ideal validation method that we strive for in migration testing. It compares every record, bi-directionally, comparing every record in the legacy system against the target system, and vice versa. Using queries that highlight discrepancies, we can then precisely assess the accuracy of the migration.

Cerdi Beltre: ​What advice would you offer to a research site contemplating a change in CTMS?

Here are the five most important considerations I would recommend:

1. Prioritize integrations that reduce double data entry. As you review your overall process, focus on what information are you duplicating in multiple systems, how frequently, and why?  What efficiencies could you gain if the information were shared between multiple systems?
2. Get a commercially available, proven CTMS. You’ll want a CTMS that follows standards for integrations, has a proven track record for product delivery and service, and shows commitment to updating the CTMS with changes in industry trends, regulatory requirements, and data standards.
3. Choose a system that will grow with you – one that meets your current needs but also can adapt as your needs grow or change in the future.
4. Standardize key statuses/timeline points to provide transparency at the enterprise level. Will your CTMS allow you to easily pull a report of your historical studies and metrics to demonstrate the expertise of your site?  For example, can you use the CTMS to demonstrate your site’s expertise to sponsors:
   • What therapeutic areas do you have experience with?
   • How many studies have you conducted?
   • How many participants have you enrolled?
   • How efficiently did you enroll in the studies?
   • What percentage of participants completed the study?
5. Assess your current system and what functionalities your team is using most frequently.  Are you using the functionality in the system that you expected to use?  Is there any functionality that you intended to use but are not using?  If so, understand why.  If this functionality would be beneficial to your team, include it as a requirement in your search for a new vendor.