Realize Maximum Value When Implementing Electronic Data Capture

Electronic data capture has a history of mixed results, but evolving technology and major shifts in the drug development market mean the industry should now revisit EDCs benefits.

During the nearly two decades that electronic data capture has been available, pharmaceutical companies have repeatedly dipped their toes into its waters, then stepped away from serious commitment. But now, with shareholders expecting continued returns of over 20%, research costs increasing faster than sales, and pricing and patents both under pressure, the need to control the cost of clinical research and accelerate time to market is paramount. PricewaterhouseCoopers estimates that the industry will need to reduce the cost of drug development by 20% to over 40%.¹

Electronic data capture (EDC) has changed significantly and can now be considered an effective way to minimize the cost of clinical research. In fact, PricewaterhouseCoopers estimates that EDC and similar advances can reduce the cost of clinical research by 20%. By understanding those changesand the requirements for implementing the technology successfullypharmaceutical companies can maximize EDCs bottom-line potential.

EDC has come a long way
Tremendous changes have taken place in the capabilities of electronic data capture technology, in the capacity of EDC vendors, and in corporate experience with EDCchanges that make EDC a reliable tool for significant business advantage.

Technology has improved. EDC technology has improved dramatically since its introduction in the early 1980s, when DOS-based systems were unable to meet the industrys high standards for validity. Current-generation EDC applications use the Web for data transactions, whether data is being entered online or offline. The advent of UML (Unified Modeling Language), XML (Extensible Markup Language), and portal technology, as well as standards promulgated by the Clinical Data Interchange Standards Consortium (CDISC) are improving the ability to integrate EDC and other key applications. The Internet is an increasingly effective and secure mechanism for data transactions, information sharing, and collaboration, and it is used in other demanding industries such as the securities business. New technologies in the works offer the potential of a true paperless clinical trial. EDC technology is ready to move past the critical early adoption stage and into the early majority stage.

Vendors have grown in scale, stability, and reliability. The large pharmaceutical companies have worried that EDC providers lack the scale and stability to support global clinical development requirements. The business profiles of established EDC vendors are much improved, but vendors have yet to achieve the scale required to meet the needs of a global drug development enterprise performing up to 1000 clinical trials per year. A good vendor assessment processone that focuses on known providers of EDC technologycan yield a successful business relationship.

Most companies have some experience with EDC and plan to increase their use of the technology. An ACRP (Association of Clinical Research Professionals) survey focused specifically on EDC received 229 responses136 from investigator sites, 41 from pharmaceutical or biotech companies, 29 from contract research organizations (CROs), and 59 from other clinical researchrelated sources. The survey indicates that almost half (49%) of the respondents companies had used EDC systems or processes. Of the respondents who had used EDC, close to 80% indicated that their overall experience was either neutral or positive.² ACRPs annual survey responses indicate that 66% of sites, 60% of CROs, and about 50% of sponsors expect to adopt electronic case report forms (eCRFs) within the next two years^.3

EDC could have significant value if it were more broadly applied, evidence suggests. EDC is currently used in only about 10% of clinical trials.⁴ Those trials are not structured in a way to prove or disprove the efficacy of applying the technology, but other data strongly suggests its potential.

In one case, EDC reduced the cycle time on case report forms from 45 days to 9 days. Transcription errors were eliminated, and data errors were detected almost immediately, allowing for early intervention. In another case, the database was actually locked on the day of the last subject visit, rather than the more typical three to six months later.⁵ Multiply that by the average 68 trials per New Drug Application (NDA) and the possibilities for reducing time to market are clear.

By reducing sponsor and investigator time normally spent on transcription errors, out-of-range data values, and similar problems, EDC frees a clinical research associate to focus on source document verification, regulatory compliance, and building relationships with site staff. Earlier data cleanup also allows for quicker and better decisions on whether to continue, expand, or discontinue a study.

An EDC action plan
Although pharmaceutical companies may not yet be completely comfortable with current EDC vendors, market forces dictate that drug (and device) development companies make the commitment to achieving maximum feasible value from EDC. Comfort level may increase as larger technology organizations start to consider EDC vendors as acquisition candidates.

To help pharmaceutical companies go beyond the perpetual piloting syndrome and to get maximum value from EDC implementation, we suggest several essential strategies.

Get top management support. Executive support is key to getting the financial commitment and substantial attention to people and process that EDC implementation requires. Only executive support can break down the organizational inertia in the separate silos of typical departmental structure, and the deeply entrenched processes and habits involved in the use of paper systems. Both must be surmounted to realize full worth from EDC.

Implement EDC through a change management process. For an EDC solution to succeed, it must be shaped by its key stakeholders. Consensus development will ultimately have more impact on what the company can achieve than will the timetable for deploying hardware.

Categories to be addressed in assessing the needs of the internal organization are shown with examples in the Change Management box. It is not only critical to involve internal constituencies but also equally important to involve the investigators and their staff members in the planning process in some way. An apparently ideal EDC design will fail if it doesnt take into account the possibility that users may have limited experience with technology.

Business process change must be an important part of the change management process. Standard operating procedures, work processes, and business continuity practices must all be reviewed to see where they need to be modified to support and work with an EDC system.

A pilot program is a key part of successful change management. Criteria for determining success must be specified in advance and the metrics used should be appropriate for a short-term assessment. EDC and paper-based systems should be compared on a best test, not stress test basis, making allowances for the learning curve, and for investigator office conditions that may be less than optimal for EDC system implementation. The idea is to compare paper systems with the best possible approximation of the way EDC will perform as a steady state system, not a brand-new one.

Once it is determined whether the pilot program is a success, appropriate next steps may include a direct comparison between EDC and the paper processmeasuring differences and extrapolating the value that the new technology might bring if truly integrated. Or the technology could be rolled out across a number of studies to expand the metrics analysis to include a broader array of variables.

One product of the change management process is a comprehensive implementation plan that addresses all aspects of change needed to maximize the value from an EDC system. This plan will include training requirements, documentation needs, user support requirements, technology administration and security, reporting, cost analysis, decision support, and change controlas well as hardware procurement, management, and maintenance.

Conduct an in-depth vendor assessment. Once a corporate perspective has been established, you may decide to work with a vendor for at least some part of an EDC solution. Even when the decision is to build rather than buy, a partnership with a vendor may provide a quicker or more reliable way to create a custom piece of the architecture. The vendor assessment process should address the categories shown in the Key Criteria box.

Select the right technology option. A number of different technology architecture (hardware-software configurations) options are available for an EDC system. These include client-server, Web-enabled, and Web-based systems. System architecture should be selected to best fit a companys requirements for executing trial tasks as those requirements are defined in its needs analysis.The hybrid model, a combination of client-server and Web solutions, is currently popular because it allows investigators, coordinators, and clinical research associates to work unplugged and in batch mode, while providing Internet connectivity and giving sponsors potentially rapid access to data.

Web-based or Web-enabled systems have many advantages, including ease of validation, deployment, and updating. Their most obvious limitations are Internet transmission speeds and barriers to connectivity. These should improve over time (as bandwidth increases and Internet access improves). As wireless technology becomes practical, it will let physicians, nurses, coordinators, and field-based clinical research professionals work online while still remaining unplugged. This has the potential to minimize the limitations they now experience because of the need to be connected while working with Web systems.

Integrate other data systems to realize maximum value from EDC. Entering clinical data by EDC becomes powerful when that technology is integrated with other clinical research tools, such as a clinical data management (CDM) system, a laboratory data system, coding tools, a safety and adverse events reporting system, and drug supply, financial, and electronic regulatory submission (ERS) technology.

Legacy systems can be a particular obstacle to integration. They are often component-driven and can be home-grown solutions or third-party products. Prior-generation EDC products had to be retrofitted to existing internal technology architecture. In contrast, third-generation products are more flexible, parameter-driven applications and should be better able to integrate with a companys technology infrastructure.

Even in our experience with more recent systems, for which integration is supposed to be no problem, we found that it takes a great deal of time and effort to move metadata and clinical data to and fromespecially tothe EDC system. Success in that effort requires addressing a tremendous number of details, from consistency in naming conventions to subject identification numbers. An integrated solution needs to deliver a consolidated high-level view of clinical trial information to a wide variety of stakeholders across the drug development enterprise.

CDISC standards. Integration should become less difficult once industry approves the standards of the Clinical Data Interchange Standards Consortium, a group composed of software vendors and sponsors. CDISC has proposed a standard that will let vendors produce a transfer file that can be read by any CDISC-compliant system. The first version of the CDISC submission metadata model was released last year. The challenge of integration is to balance overall business processes, workflow and user requirements, and legacy source systems with the EDC product.

A new approach
Obtaining maximum value from EDC requires a new and more comprehensive approach to implementation. Top managers must direct a change management approach that addresses the entire spectrum of business processes in the clinical research division, and involves the major internal and external stakeholders. Those participating in the planning process need to learn about the options for EDC systems architecture, and determine which alternative appears likely to produce the best results. Careful consideration must be given to the build-or-buy decision with a view of corporate core competencies, and whether and how to use vendors. The task in vendor evaluation is to find the best fit among established EDC vendors and determine what relationship will provide the best obtainable level of comfort.

Finally, in todays climate, knowledge management is a core competency for pharmaceutical companies. Maximizing value from an EDC system requires that it be integrated with existing and planned information systems to build an information-rich environment for business operations and decision-making.

References
1. Pharma 2005: An Industrial Revolution in R&D (PricewaterhouseCoopers LLP, 1301 Avenue of the Americas, New York, NY 10019) 1998.

2. Electronic Data Capture: Survey 2000 (Association of Clinical Research Professionals, 1012 14th Street NW, Ste. 807, Washington, DC 20005).

3. Association of Clinical Research Professionals, ACRP White Paper on the FutureWhere We Are and Where Were Going, The Monitor, Summer 2000.

4. Pharmaceutical R&D Statistical Sourcebook 2000 (Parexel, Rose Tree Corporate Center, 1400 N. Providence Rd., Ste. 2000, Media, PA 19063).

5. Brian Chadwick, To e or Not to e, Pharmaceutical Visions, Spring 1999.

SIDEBAR: Change Management
Assessing the needs of internal constituencies in the organization is a vital part of planning the change management process and should address the following issues.

1. Stakeholder requirements, such as
2. Monitoring and reporting tools
3. Online/offline data entry (or both)
4. Access
5. Cultural or logistical issues
6. Financial and resources commitment, such as
7. Preferred form of license
8. Costs for technology knowledge transfer and/or vendor services
9. Cost of implementation, maintenance, etc.
10. Risk profile and risk management, such as
11. Security requirements
12. Password administration
13. Process analysis, such as
14. Standard operating procedures
15. Work processes
16. Business continuity practices
17. Business rules analysis, such as
18. Dataflow, workflow
19. Technology integration objectives, such as
20. Short- and long-term integration requirements
21. Clinical database management
22. SAS datasets
23. Electronic regulatory submission
24. Finance
25. Project/trials management
26. Fit with broader technology strategy, such as
27. Effect of other planned technologies in the division and company
28. Buy/build assessment, such as
29. Analysis of vendor offerings strategy
30. Customization and optimization
31. Cost and time
32. Time to mature application

SIDEBAR: Tufts Calculates Cost of New Drugs
The Tufts Center for the Study of Drug Development (Boston, MA) estimates that the average cost to develop a new prescription drug is $802 million.

The figure is the major conclusion of a recently completed study based on information obtained directly from research-based drug companies. The estimate accounts for the cost of failures, including research abandoned during development, and the opportunity costs of incurring R&D expenditures before earning any returns.

Ten years ago, the average cost of bringing a new drug to market was $231 million. While costs have increased for all R&D phases, the increases are particularly acute in human clinical research. The inflation-adusted annual growth rate for capitalized clinical costs was more than five times that of preclinical R&D.

SIDEBAR: Key Criteria in Vendor Assessment
The vendor assessment process should address the following categories and criteria.

1. Business profile, including
2. Years in business
3. Corporate partners
4. Number of employees/offices
5. Financial stability, including
6. Ownership
7. Financing
8. Current and historical profitability
9. 21 CFR Part 11 compliance, including
10. Compliance with FDA requirements for documentation, training, security, and auditability
11. Domain knowledge, including
12. Knowledge of clinical trials
13. User familiarity with industry regulations
14. Experience, including
15. Type of customers
16. Number and geography of trials
17. Metrics available
18. References, including
19. Overall customer satisfaction
20. Ease of implementation
21. Smoothness of update process
22. Support, helpdesk, including
23. Coverage for all time zones
24. Helpdesk software and policies
25. Multiple language capabilities
26. Pricing, including
27. Pricing algorithms
28. Annual contract vs. project-based approach
29. Hidden costs
30. Customization and optimization, including
31. Capability
32. Willingness
33. Future development plan, including
34. Planned upgrades, frequency
35. User input
36. Release compatibility
37. Plans for new system architecture
38. Ancillary tools, including
39. Reporting tools (e.g., Crystal Reports)
40. Local client database (e.g., Oracle Lite)
41. User interfaceease of use, including
42. Interface intuitive for investigators
43. Menu systems
44. Acceptable response time
45. Integration profile, configuration requirements, including
46. Data flow (bi-directional)
47. APIs (application program interface)
48. Data output definition

Brian J. Chadwick*is co-founder of eP2 Consulting LLC, 7 Faith Walk, Cortlandt Manor, NY 10567, (914) 739-4573, fax (914) 734-7876, email: bchadwick@eP2Consulting.com. Susan Nonemakeris practice manager at Intrasphere Technologies, Inc., and Michael R. Bienis a partner at eP2 Consulting.

*To whom correspondence should be addressed.