Clinical Practice Lead for Daelight Solutions

Teresa Montes

As the past two years have certainly reinforced, the clinical landscape evolves at a rapid pace. For example, the coronavirus pandemic spurred the need for new vaccines. It took only 11 months

 for the first COVID-19 vaccines to go from the development stage to being granted emergency use authorization.

At the same time, technology keeps improving and changing the way we get work done. As a result, there is a near-constant need to adjust systems and ensure operations are up to date and compliant. To keep up with the latest industry updates—while keeping data sources and trial portfolios up-to-date and secure—technology integrations are front and center.

This article discusses the need for integrating clinical trial technology stacks, best practices for integration, and the steps organizations can take to make this happen.

Clinical trials are all about collecting data to prove whether a compound is safe and effective. High-quality and compliant clinical data relies upon the work of many individual teams working on everything from monitoring and management to TMF documentation, from study startup to subject and visit management, and even personnel tracking and vendor management.

All of these activities depend upon each other, which means the function-specific systems need to be able to communicate, share progress updates and reference information. The technologies used to manage the data for these various domains are often disparate. The very integrity of clinical trial data, therefore, depends on creating data consistency across the domains—ultimately dependent on the quality of your technology stack’s integration.

An integrated tech stack ensures all the tools and applications work together to provide a holistic solution for the integrity of your clinical trial data. If all functions are not available in a single system, validated integrations provide proof of control over your shared data. Integrations are a huge time-saver given the ability to automate data updates across systems that would otherwise be difficult, time-consuming, and prone to error if handled with a manual process. Better data management can even lead to faster clinical trials overall.

While the value of integration is high, the project costs are not trivial. Fully tested and beneficial integrations require their own funding, requirements, and implementation work so it is important to know the best practices for a clinical trial technology integration before you jump in.

Best practices for clinical trial technology integration

Appropriate planning is the first step in building any integration initiative. Look for the path of least resistance. Assess what is available in the environment already. If the expansion or reuse of an existing integration is possible, explore that opportunity as possibly a faster, more cost-effective option.

Once you scope the change and systems impacted, focus on the following five areas to uncover potential issues and resolve them before the integration goes live.

Investigate expected data volumes and learn the amount of time available for your integration to make data updates. System timeouts for long-running processes will revert your data or worse: leave partial updates in the target system. As a general rule, project the greatest possible volume your integration will need to handle.

Significant volume may result from day one for production, the introduction of new data sets from acquisitions, or significant portfolio growth. Your integration process needs the means to handle these stressing volumes, as easily as day-to-day operational data updates. Use boundary situations to give you the volume numbers to compare to the integration capacity within the available time frame.

You may need a little creativity around how you deal with large volumes, given available time for updates and your system or tool constraints. Solutions to deal with high volume stress are easier managed when identified, incorporated in the plan, and tested in advance.

Before you begin an integration, consider the types of data that will be shared. Master data may be stored in a central system or generated by a single system and shared across the domain. Evaluate the opportunity to pull this data directly from the authoritative source to assure the timeliness and veracity of your data.

For example, the Investigator's Brochure would be shared across clinical and regulatory systems. You will want these to be used in Clinical, although the authoritative system is in Regulatory. Gaining a thorough understanding of authoritative data sources will build a solid foundation for decisions on the direction of the integration.

Next, ensure your source and target systems are able to share the same data without creating errors. Historically, systems may have fields with the same name, but different sizes or data definitions. Your integration needs rules to document any data value or format changes to assure compliance. Whenever possible, maintain alignment to the authoritative source data definitions.

3. Investigate any triggers in the target system

Another task on your to-do list is to investigate any triggers in the target system. For example, when entering the last visit for the site’s subjects, the last patient visit milestone completion may be triggered, and the date recorded. Be sure to plan for these triggered activities when testing the integration.

4. Document everyone’s responsibilities

Getting a project like an integration done efficiently and effectively takes a team effort. With that said, it’s important to know the personnel and systems involved, their roles, and interest in delivering the project. Make these expectations part of the documentation and communication for the project. Misunderstandings in responsibilities may result in a redundant effort, incomplete activities, or system implementation failures. Avoid these pitfalls with effective team communications.

For post-implementation, you want to ensure all stakeholders are clear on who is responsible for the ongoing support of the integration. Assign decision-making rights for the evolution of the integration and align the stakeholders impacted by the integration.

Finally, agree on who owns decision-making authority for portfolio management and fiscal oversight of the integration over time. Changes to process, content, and upgrades will need funding and resource planning.

5. Determine what to integrate—and plan for failure

You have one remaining item to plan: Which studies to include? When you have studies that range from relatively new to long-running, not all may be reasonable candidates to use the integration. Understanding that variability in your study environment will help you determine if all your studies should have the integration turned on at launch or to identify the situations when you should disable integration updates.

Remember, even the most elegant integration solutions can have issues. Your implementation plans need to allow for the management of failures. Have options for correcting production data ready in advance such as restoring corrupted elements to their original state or utilizing a manual update to mitigate the issue. A viable backout strategy will reduce organizational stress, in case of an error.

With clarity on decision-making responsibilities, now consider staffing. A capable team is a vital factor in your project success.

Take a step back and answer these questions:

Is it okay to use in-house staff, or should you be using outside help?

A capable team relies on the contribution of professionals from multiple areas. Technical expertise in integrations is a must. Partner technical expertise with subject matter experts from each system involved in the integration. These experts will need to speak to volume, business process, and system use.

Strong business analysis and project management will keep the project focused and moving forward while providing necessary progress updates to an engaged and supportive leadership team.

The support of the security, validation, and privacy teams is often overlooked in the initial planning. Engage these teams early to align on specific communication and requirement needs.

Team resources with demonstrated experience and the ability to dedicate the needed time to the project will improve the likelihood of your project success. Skilled resources reduce the risks of slips on timelines or budget overruns. External, specialized resources may be needed to supplement your team, if there is a lack of skilled internal resources with the ability to dedicate sufficient, focused time to the project.

It’s better to encounter issues early in the project execution than when you’re about to go live with the integration. You may end up with short-term costs but a better return on your integration investment by considering integration resourcing needs early—including people and the environment.

Now’s the moment you’ve been waiting for: implementing your integration. You’ve gone through all the planning and know the best practices, so now it’s time to flip the switch and move your portfolio data.

When an integration initiative is well-planned and successful, you reap many benefits including a reduced risk of failing compliance standards, enforced consistency across systems, and standardized data at an enterprise level rather than per system.

Active clinical trials generate data at an exponential pace. When you have a large volume of data, it’s best to have the systems integrated so you reduce the risk of costly errors and frustration. The life sciences industry is a tightly regulated space and failing to manage compliance jeopardizes not only your time and money but also the important therapy you’re trying to test and bring to market. Performing a technology integration right the first time often proves to be faster, cheaper and more compliant—and you won’t have to wonder if your data is correct because it will be standardized at the enterprise level.

Follow these best practices for clinical trial technology integration to keep your data secure and in compliance, moving you one step closer to bringing your product to market.

 is a Clinical Practice Lead for Daelight Solutions

https://www.sciencenews.org/article/covid-coronavirus-vaccine-development-speed

https://www.appliedclinicaltrialsonline.com/view/driving-clinical-speed-and-agility-post-covid

Articles

Data is the heart of clinical trials, so life sciences firms need to integrate their technology to keep data sources and trial portfolios up-to-date and secure.

Best Practices for Clinical Trial Technology Integration

Clinical trials build a profile of a compound to answer: Is it safe? Is it effective? Is it better than other offerings on the market? The cost of gaining this knowledge is high, so maximizing the utilization of the knowledge collected through the trial is essential.

Individual systems or a few integrated systems provide a reasonable view of the data collected within a small domain, but growing organizations need to bridge data from multiple systems to support analysis across the clinical operation.

Data used to drive operational decisions is generated by a variety of contributing areas, including biostats, essential documents, clinical supplies, patient reported outcomes, protocols, disease prevalence and genetics, to name only a few. The list of data sources expands every day. Integrating data sets from different clinical systems opens paths to pursue answers for difficult questions, previously impossible to answer using one or two linked systems.

Clinical goals change rapidly, as clinical teams work to improve and save lives. Limits imposed by a lack of data inhibits the chances for success. In addition to assessing past and current progress, large, integrated sets of data are the essential to activate the power of Artificial Intelligence (AI) and Machine Learning (ML) tools to better project outcomes.

Integrating data from across clinical systems requires investment. So, the question becomes, how much integration is needed and how big is the investment? As you choose the integration options, building a strong understanding of the data is a critical, foundational first step. Using your integrated data successfully depends on this first step.

Managing data across multiple tools requires an understanding of the data connection points. Looking at an example, you may want to observe trends with patient data quality, across studies, for a particular clinical site. To do this you need to look at potentially one system for study sites and locations, and possibly a different system for information on the organization. Next you gather contract information and find the site data quality and timeliness information in a different system.

Doing this task can be difficult. You need to be certain that the site information matches correctly across systems and they have the same organization, the same physical location and the same department.

Across systems or within systems, data may be inconsistent. You may see something as common as multiple studies using the same physical site, although they have different site numbers in each study. Having different names or a site, or errors in data entry such as multiple versions of organization names, can make compilation of a full picture nearly impossible. 

When you successfully associate your data across systems, the value of your data greatly increases; you create an opportunity to track site performance without investing in new site tracking systems. Getting an understanding of your data, within and across systems, is the single, most important factor in making your data aggregation work. Resources invested in standardizing data reap huge benefits.

Determining the definition of the data (e.g., study start date: What event is the starting point for a study?) and the relationships between pieces of information (e.g., do clinical studies have one or more indications; no indication?) allows you to use collected system data to address a larger number of business questions. As more integrated system data is available from both within and outside of the organization, new business insights can be harvested. 

As an example, consider the potential number of available patients fitting the clinical study protocol requirements within a reasonable radius of a site. When considering funding and expected study completion timelines, this is a reasonable question to ask. An analysis of this question would consider the protocol requirements, demographics of the local population, the transportation opportunities for the target population and the number of competing specialists in the area around the clinical site. Working with individual systems and one-off queries of external data sets, this task becomes time consuming and error prone. Combining data from confirmed internal and external systems makes this an easier question to address. 

The task to define and test the combination of data requires resource commitment. How much will you need to start? Consider the areas of greatest need and risk, which provide an obvious avenue to begin the data integration journey. The risks you identify, such as data integrity needs across systems or data sets with limited availability, will inform choices between options for integration. 

Different price points and levels of flexibility exist, depending on the scope and functionality required for a data integration. In many cases, a single organization may utilize more than one of the approaches described below.  



The platform solution hosts multiple functions in one tool. Why build interfaces when you can buy a tool that has consolidated the data and built the basic relationships? A platform solution provides multiple sets of functionalities, such as essential document management, trial management, study startup support and site communications, built into a single tool. Given that all of these functions relate to a clinical study, the structure is shared. Data is captured once and automatically shared across all uses. 

With the platform solution, organizations must still manage data integrity, such as assuring there are not three versions of the same Jay Smith in the list of investigators. This solution will not be suitable for every organization, as the introduction of new systems can be costly.



Integrated applications allow your tools to work together, despite being independent systems. Connectors exist to allow users within one system to access documents or data from another system, without having to leave their current interface. As an example, regulatory teams working on a submission may open a view into the eTMF system to link to a document of interest. Connectors are purchased separately and work with a limited set of systems.




Point-to-point system integration depends on building tools to share data. For example, product management information can be shared with a clinical study system to assure integrity is maintained in the use of the data. When the integration tool is triggered, identified data updates in the source system push to another system.

These point-to-point integrations have been around for a long time and vary in complexity. The simplest tool is the Excel sheet, used to format data sets following strict formatting rules. The file is used to allow users upload data sets, and user groups trigger the updates, when needed.

A scheduled data update may be tied to the clock or result from a change in the data. An integration tool checks for the trigger. When started, the backend routine pulls data from the source and pushes the update to another system.

A newer option in this category is Robotic Process Automation (RPA). Conceptually, the robot (in ‘Robotic’ Process Automation) learns a set of update actions, based on data provided. You may recall using macros in Excel; a user programmed steps by memorizing keystrokes. RPA expands on this idea by applying AI and ML. The robot learns by watching users process updates. If a particular set of conditions exist in the input data, then the user normally takes a specified update action. Once trained, the RPA software is able conduct update steps, based on a complex pattern of inputs built and learned by the tool. Corrections over time hone the algorithm, improving accuracy. This approach allows the robot to replace repetitive user actions. 

The costs for point-to-point solutions align with the complexity and robustness of the solution. The Excel solution takes minimal upfront investment, although it is labor intensive and prone to input error. The RPA option is more expensive and requires training time, but after initial learning routines, the maintenance is held at a relatively low level.




Moving away from a direct system A to system B connection, a hub and spoke design pushes data sets to a central storage location. This central storage area will allow other systems to consume the data, potentially provided by multiple systems. 

In these models, data definitions and data relationship definitions are needed to provide data to consuming systems. The difference between the options below is when those definitions and relationships need to be built. 

Traditional data warehouse models predefine all pieces of data, integrate the data into a data model (hard-wiring relationships), establish rules about reliable data sources and support the generation of data views for consumer systems. Data warehouse models rely on the data definition and relationship work being completed before storing the structured data sets. Maintenance on these systems tends to be high, as new data sets may impact the existing schema for the data.

Data lakes provide a way to ingest structured and unstructured data sets of varying size. Like books run through a blender, all the pieces of data are held there. To be useful, they need to be assembled. Data lakes allow for the definition of data relationships after the data is stored. To extract and use the data, relationships must be built. 

Leveraging data from sources both within and outside the enterprise may provide new and interesting opportunities for investment, resource planning, study planning and knowledge reuse—all essential for making the greatest use of information collected in and around clinical trials.

Clinical Consultant; both for Daelight Solutions.

To have a successful integration of data from across clinical systems, a strong understanding of the data is a critical.

Teresa Montes

Articles

Best Practices for Clinical Trial Technology Integration

The Value of Integrated Data Views for Clinical Trials