The Business Behind Technology Choices

March 2, 2007
Shaghig Palanjian, Kate Trainor
Applied Clinical Trials
Volume 0, Issue 0

Business needs and the processes built to support them are the driving force behind sound technological decisions.

Technology has always spurred the development of more technology. The wheel, for example, has spurred new technologies ever since its invention in ancient Mesopotamia. Its role in transportation has given us bicycles, trains, automobiles, airplanes, and even skateboards.

Selecting the right technology to optimize clinical development of a new compound or medical device is not unlike choosing the right method of transportation. Both decisions weigh elements such as speed, safety, cost, accessibility, and user ease, which all link to the bigger picture: how each technology can help the user achieve their goals.

Solution selection

Like the wheel, electronic solutions in clinical research have come a long way. In the past 10 to 15 years, they have evolved from single-function desktop applications circa the pre-Internet era into multifunctional, integrated Web-based tools critical to process improvement. Clinical stakeholders have invested heavily in front-end electronic data collection tools and back-end clinical data management systems, all seeking to cash in on the promise of speedier timelines, boosted by efficiencies in data collection, transfer, analysis, and submission.

And as technologies have become more comprehensive, it is not surprising that many now have overlapping functionality. Patient recruitment and enrollment activity, for instance, can be tracked by an interactive voice response system (IVRS), an interactive Web response system (IWRS), or an electronic data capture (EDC) solution. So with all the available solutions, how does a company know which is the right technology for its program?

This article explores the notion that the best decisions about technology are driven by the business reasons for a proposed study and the business processes built to support those reasons—not the other way around. In other words, the medical needs of the protocol and the development program should be the driving force, with technology playing a supporting role. (Two case studies presented document the value of this approach.)

Business first

Too often clinical programs are launched with minimal attention paid to the program's business need.

Business needs come in all sizes. Some are big picture and focus on major initiatives to expand the use of electronic solutions across the enterprise to improve operational efficiencies and safety. Others are study specific (see Figure 1) and address highly defined issues such as the best way to randomize patients in a multicenter emergency-room based study (e.g., is an ER environment better suited to a Web-based or IVRS?) Regardless of the size of the business need, it is the starting point for selecting the right technology.

Figure 1: Identifying the Business Need

From the outset, the clinical team must identify the business purpose and then hammer out the kinds of processes needed to support it before the right technologies can be put in place. Building the business processes to address the need begins by identifying areas that can benefit from an automated approach. The task involves exploring the kinds of technologies that can be integrated with the greatest efficiency, scalability, and return on investment (ROI) to produce high-quality clinical data.

Business processes are impacted by factors such as therapeutic area, trial size, number of investigative sites, geography, and complexity of the protocol. These factors should be taken into consideration by the clinical IT team in their discussions about where and what kind of automation is needed and the potential for integration. Discussions are necessary, as technologies increasingly have overlapping capabilities that are not necessarily interchangeable. For example, if a sponsor has access to personal digital assistant (PDA) and ePen technologies, are they equally useful in a global study expected to enroll mostly older subjects who will be asked to record daily quality-of-life observations, or is one choice better than the other?

Major players

Building the required processes is not a simple one-size-fits-all activity because studies vary dramatically. Also, sponsors run the gamut: from highly sophisticated operations with heavily resourced IT departments to young start-ups with minimal infrastructure. There are basic building blocks, however, that operate as the framework for a study and provide stakeholders with access to real-time data as the trial unfolds.

The clinical trial management system (CTMS) is one enterprise-wide solution that many companies adopt as its source for a central database for all nonclinical and some clinical data. It may integrate with modules that manage routine functions such as site recruitment, randomization, finance, planning, IRB monitoring, supply tracking, and electronic data capture.

The clinical IT team, generally composed of IT staff, data managers, and clinical staff, has the job of setting up the study and building the processes in-house or opting to partner with outsourced vendors for some or all of the work. In either case, the clinical IT team is responsible for selecting the right technologies—a task accomplished by asking lots of questions about the capabilities of the existing infrastructure, how and where the technology will be used, how it will be deployed, and how it will serve the business reasons for the study.

The kinds of questions asked may change as clinical staff members increase their participation in the IT clinical team. Typically, technology decisions are made by IT specialists or data managers because of their technical understanding. Clinical staff members tend to be somewhat disinterested in this activity, as they view it as peripheral to their other responsibilities—or they lack the technical expertise. But because study conduct is about medical people performing the protocol and using the technology selected, their needs can be better represented by clinical members on the clinical IT team.

IT staff, for the most part, are removed from clinical development work, so by increasing the visibility of the clinical members, the clinical IT team is more likely to strike a balance between technical requirements and medical professionals' preferred style of workflow.

Real life examples

Clinical IT teams that accept more input from clinical members will begin to have a greater understanding of the medical and doctor–patient issues created by the specifics of each protocol. As the following real life examples show, both medical and IT voices are needed to choose the technologies best able to handle the many human aspects of conducting Good Clinical Practice (GCP)-compliant clinical research.

Case Study 1: Collecting & integrating scan data. A biopharmaceutical sponsor is engaged in a global Phase III program for an investigational compound to treat a condition for which there is no effective therapy. The protocol requires a scan for screening purposes, as well as multiple scans throughout the study. The sponsor is seeking a comprehensive, integrated system that can accept images and enable site personnel to enter results into the data collection system. Because of the global nature of the study, the client prefers IVRS to track images, which can easily be sent via the Internet.

To develop the business process, the sponsor opts to partner with an informatics provider experienced in building solutions able to accept imaging data. The provider's IVRS is designed to collect site and imaging status information, such as images received, QC performed, preliminary inclusion values met, and radiologist reviews. Once confirmation is provided in the IVRS, the system automatically updates the medical imaging system on image status. The IVRS also collects a wide range of study metrics, such as patient enrollment and randomization status, and integrates with the clinical trial management system (CTMS), which investigative sites can access through a portal. (Data flow is shown in Figure 2.)

Figure 2: Data Flow from Study Startup to Image Tracking

During the vendor selection process, the sponsor considered choosing one vendor for the CTMS and another for the IVRS. Although this was possible technologically, it would have had dramatic implications. For example, using two different vendors would have included significant incremental costs and unknown difficulties related to data mapping—the probability of incomplete mapping was high, as were costs associated with building an interface to accept the scanned data into the IVRS as well as an interface between the IVRS and the CTMS. In addition, changes would have had to be made to the investigator portal.

Case Study 2: Improving trial efficiencies. A large pharma company is engaged in a system-wide program to optimize global clinical trial operations through enhanced technologies that will enable greater process efficiencies. A substantial infrastructure is already in place, including a CTMS, a site management system, and a tool to help with investigator and site identification. Going forward, the sponsor seeks processes that will accelerate study start-up; improve workflow, monitoring, and regulatory activities; upgrade site management capabilities; and reduce redundant efforts.

To reach these goals, the sponsor chooses to work with an informatics vendor able to provide solutions that can be integrated with the existing CTMS on a global scale (see Figure 3). Depending upon function, the solutions can be accessed by clinical teams, data managers, executives, investigators, and subjects, and include modules designed to provide faster site recruitment, better document tracking, and centralized monitoring. There is also an Investigator Communications Portal, which gives the site access to modules that track and manage study metrics; patient enrollment status and visits; financial information; and other program and therapeutic specifics.

Figure 3: Data Integration Goes Global, Saving Sponsors Time and Money

Using the CDISC Operational Data Model (ODM), the modules are able to share common data related to study start-up, patient enrollment, and EDC, eliminating redundancies.

Since implementation of the additional modules, early results indicate substantial savings potential in the area of patient over-enrollment, as investigators have accurate, current information, which limits the risk of enrolling past predefined goals. Also, site and patient compliance has improved due to real-time connectivity, incentives, and measurements.

Looking ahead

Electronic solutions are pivotal to improving clinical trial efficiencies, but focusing only on the technology obscures the bigger picture: How to leverage its use to maximize ROI. Without considering the business purpose of a clinical trial or how parts of the trial can best be managed, the technology that is used may result in critical internal process conflicts for sponsors, and less than optimal data collection and data flow.

Shifting the focus away from technology and toward business reasons and business processes can improve clinical efficiencies, timelines, and cost. And importantly, this could lead to better and safer biopharmaceuticals and medical devices—an increasingly visible issue for the industry, the public, and regulators across the globe. In late January 2007, the FDA announced its comprehensive commitment to increased safety of medical products, based on a set of recommendations made by the Institute of Medicine in 2006.

The initiatives to be adopted by FDA will likely spark further use of electronic solutions in all phases of clinical research. As this effort unfolds, there is even more reason to implement and select technology with careful forethought.

Kate Trainor* is vice president, integration services with Perceptive Informatics, 900 Chelmsford Street, Lowell, MA 01851, (978) 677-3827, email: kate.trainor@perceptive.com Shaghig Palanjian is vice president, world wide technology implementation, with Parexel International.

*To whom all correspondence should be addressed.