sites + edc does not have to = pain · survey users want a faster login process and more than 40%...

7
Produced by Cambridge Healthtech Media and eCliniqua Custom Publishing Contributing Author: Deborah Borfitz www.cmedtechnology.com Sites + EDC Does Not Have to = Pain Building eClinical Platforms for Real-World Scenarios

Upload: others

Post on 20-Jul-2020

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

Produced by Cambridge Healthtech Media and eCliniqua Custom Publishing

Contributing Author: Deborah Borfitz

www.cmedtechnology.com

Sites + EDC Does Not Have to = PainBuilding eClinical Platforms for Real-World Scenarios

Page 2: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

2

colleagues who are available at a moment’s notice for technical troubleshooting. Clinical research may take place in a private or public practice setting where multiple people share a five-year-old PC with one Internet connection or at a metropolitan hospi-tal provisioned with a large but congested computer network. In emerging countries, sites may be situat-ed in remote locations where Internet connectivity is “iffy”—or not available at all. Reaching patients may well require that sites are equipped with an assort-ment of mobile and wireless devices as alternative ways to conduct data entry.

It’s been claimed that EDC and eClinical ven-dors tend to neglect real-world on-site challenges and IT infrastructure constraints that doctors, nurses and clinical research associates (CRAs) face on a daily basis. Because of the aforementioned challenges, sites are pining for “zero downtime” so eClinical systems are always on all the time, ensur-ing their work is never interrupted. They want the ability to work offline—just like with emails sys-tems—so they can continue entering data regard-less of network connections. And sites do not want to rely on IT support.

Today’s eClinical vendors need to undergo a paradigm shift of how they perceive, build and support EDC systems intended to be used by doc-tors and nurses at clinics and the CRAs who sup-port them.

eClinical platforms based on cloud computing and mobile technologies can solve these problems and are being viewed more like the Amazon.com and Facebook Web sites as well as the Google search engine; that is, global utilities that are al-ways available. They have no periods of downtime

Sites + EDC Does Not Have to = Pain

Building eClinical Platforms for Real-World Scenarios

OVERVIEW

Last year, the topic of “EDC causing sites pain” was widely documented in several industry publica-tions1 and even attracted a viral following on so-cial media sites such as LinkedIn2. However, this was not the first time this issue has arisen. In 2001 and 2009, the eClinical Forum conducted surveys3

about what site users want—and don’t want—from electronic data capture (EDC) systems. Some of the common pain points include:• EDC systems being slow and causing servers

to crash at key peak times, especially during interim analysis (IA) and database lock (DBL),

• Being tethered to high-speed Internet connec-tions,

• Not being able to access all the clinical data when needed,

• Choosing between clean data and fast data, i.e., turning off validation checks.

For larger trials, these challenges get even more complicated. Sites can be spread over many loca-tions across the world and time zones. As a result, it is always in the middle of someone’s work day somewhere, meaning there are no open windows where you can freely shut down or re-boot the sys-tem to perform a mid-study change or system maintenance. If you do this, you interrupt clini-cians in the middle of their work. That causes pain.

Traditional EDC solutions often overestimate the resources sites have on hand to cope with technolo-gy. Investigators and study nurses do not work in the same environment as software engineers with their powerful PCs, oversized PC monitors, super high-speed networks and information technology (IT)

Page 3: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

3

because of scheduled software maintenance or up-grade releases. Sites today require an eClinical sys-tem that is consistently fast—just like Google—no matter how large the trial is or how many people are using it at the same time, even during busy pe-riods like DBL. Using cloud and mobile technolo-gies, study teams can add unlimited sites, patients, electronic case report forms (eCRFs), edit checks and additional study team members from all over the world without affecting the performance of the eClinical platform.

DEFINING CLOUD COMPUTINGThe term cloud computing may mean many things, depending on whom you speak to. The Na-tional Institute of Standards and Technology (NIST) defines cloud computing as a:

Model for enabling convenient, on-demand net-work access to a shared pool of configurable com-puting resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal manage-ment effort or service provider interaction.4

NIST defines five essential characteristics that systems must achieve to fulfill the cloud model: (1) they must be available on-demand, (2) they must be broadly accessible, (3) they must tap geographi-cally distributed resources to support customer de-mand, (4) they must have the elasticity to rapidly scale without delay, and (5) they must provide a consistent, measured performance regardless of demand, location or time of day.

NIST’s definition also translates to the clinical world based on the following essential clinical op-erations characteristics: 1. On-demand. Enable study managers to: go

live with trials, add sites and users, perform mid-trial changes, add or modify third-party data sources, and perform real-time reporting and interim analyses on-demand—all without delay or interruption.

2. Globally accessible. Optimize patient enroll-ment wherever sites are located and operate with complete and current access to clinical data and functionality—across all time zones; over the Internet and mobile phone connec-tions; and even offline. Enable users to choose their preferred device: a PC, netbook, mobile device or tablet.

3. Efficient and trusted. Allow even a single trial to benefit from large economies of scale, pro-

viding reliability and security without needing a large-scale investment. Clean data at the time of capture, regardless of source. Provide complete redundancy to assure no downtime or interruption—even when faced with disas-ters or data center outages.

4. Elastic or flexible. Rapidly scale capacity to provide exactly what is needed, when it is needed: for small primary-care provider offic-es or large hospitals, for a single Phase I clinic or hundreds of late phase sites, all at once for a small proof-of-concept (POC) trial or in line with enrollment for large mega-trials. Enable study managers to only pay for what they use, when they use it.

5. Reliably fast. Provide all users fast and consis-tent performance at all locations, at all times, regardless of local infrastructure—for trials large and small, during idle times and busy pe-riods (even during DBL and large laboratory data loads).

Google is deemed to be a “real cloud” because it works when you need it, everywhere, all the time and quickly regardless of how much you use it. eClinical platforms incorporating cloud computing and mobile technologies let you run trials anywhere, without large infrastructures. It lets you make changes on-demand, without interruption. It pro-vides complete and current access to clinical data and functionally quickly and reliably to everyone who needs it, using whatever method of access is best. Mirroring the Google paradigm, eClinical plat-forms enable study teams to operate more efficiently, in more places, with more freedom and flexibility.

MOBILE TECHNOLOGIESThe needs of today’s real-world sites have changed. Sites do not want to be tethered to only broadband. They want EDC to work when there is a fast Inter-net connection, when there is a slow one and when there is none. As such, they want an alternative when the network is offline. Think about how smartphones work. People can still write emails on the Apple iPhone® or the RIM Blackberry® even when they are offline while on a plane. And they are still just as fast. As soon as the plane lands, ev-erything is synchronized in the background and up-to-date. Even offline, sites need to have full ac-cess to their data, edit checks and all other func-tionality via the mobile devices.

Some eClinical platforms are extending an au-

Page 4: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

4

tonomous piece of the cloud inside clinics so inves-tigators, nurses and monitors can perform full EDC functionality in a regulatory compliant fash-ion using any WiFi-enabled mobile device: from a standard laptop to a touch screen tablet, such as the Apple iPad®. Even Android™ and Apple iOS-based smartphones can be used.

Allowing sites to use popular mobile devices gives a seamless user experience anywhere and at anytime when conducting data entry or validating information. Additionally, investigators and study coordinators are no longer shackled to one work-station. They have the means to perform their work on everyday equipment they already know, thus eliminating any learning curve.

EDC IS TOO SLOW, SERVERS CAN CRASHSpeed remains a chief deficiency of EDC after more than a decade of technical “enhancements.” According to the eClinical Forum, almost 45% of survey users want a faster login process and more than 40% want faster page turns from EDC sys-tems5. Simply logging in may be a five-minute or-deal6. Transmitting a single page of eCRF data can

take 30 seconds—and longer still, if lab data is si-multaneously being uploaded7.

EDC servers are famously prone to crashing at critical trial junctures, forcing data entry to cease and aggravating study nurses by having them post-pone correcting errors and responding to queries. Servers crash often during IA as well as DBL when sponsors add users to the system to close out the trial faster. During large lab loads, the system can slow, then crashes due to resource contention. This means data managers (DMs) have to delay lab loads to lower usage periods—interrupting those in time zones where this falls mid-day. Additional-ly, making mid-trial updates, such as protocol amendments or worldwide system maintenance, often cause server crashes.

Remedy and AdvantageseClinical platforms built on the cloud’s on-demand and elastic capabilities are free of these defects. EDC capabilities can be efficiently accessed from anywhere, including where the Web is fragile, without losing any accuracy in the data. As a result, there is enhanced performance and speed with the computing load spread across different data centers around the world, eliminating congestion

Site Challenges Traditional EDC Systems Cloud and Mobile Technologies

EDC is slow, servers can crash

Single database architecture with clinical and lab data maintained on one server in a single far-off data center

Computing load spread across different servers in different data centers around the world enhances speed and performance, eliminating congestion spikes and providing zero downtime with 24/7 operations

Work without being tethered to high-speed Internet connection

Internet cabling is needed to perform all the clinical trial work

Full data communication is maintained using only mobile and/or low-speed connections, giving sites full access to their data and edit checks even when offline

Not being able to access all clinical data when needed

Different clinical trial data is contained in separate databases

All users work from the same data from a single source, at the same point of time regardless of role or location, avoiding re-work caused by incomplete or out-of-date insight into clinical data

Choosing between clean data and fast data

Limiting the number of edits per page or turning them off entirely to not compromise speed during high usage periods, such as when loading batch central laboratory data

Firing unlimited edit checks at the point of capture, ensuring one set of validation checks will work for data from all participating sites

How Traditional EDC Systems Handle Site Challenges Vs. eClinical Platforms Based on Cloud and Mobile Technologies

Source: Cmed Technology

Page 5: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

5

spikes that occur with typical enterprise platforms during peak use periods when traffic is simultane-ously directed to centralized servers and databases.

During key busy periods, including enrollment deadlines, IA and DBL, cloud-based eClinical plat-forms can elastically scale up capacity to match surges in usage and data management staffing to ensure the system is fast at all times. Capacity for new studies, sites and users can also be provisioned without adding, integrating and validating new hardware and systems infrastructure.

The need to operate 24/7 without interrup-tion—even when modifying trials or performing systems maintenance—is also referred to as the zero-downtime model. Clinicians can execute amendments, add edit checks, etc., all without re-ceiving those annoying messages from their IT de-partment: “Stop using the system at time X so updates can be made.” As a result, eCRFs and edit checks can be updated and upgraded without downtime.

WORK WITHOUT BEING TETHERED TO A HIGH-SPEED INTERNET CONNECTIONGripes about EDC systems also have focused on being tethered to high-speed Internet connections or the lack of them at sites. Some sites state they are “stuck to a wall” with Internet cabling in order to perform the clinical trial work. Because of a site’s location, it may not be feasible to provide every doctor and nurse high-speed broadband. This is not just a problem in emerging markets, such as in Third World countries. It can be found often in the First World, such as in busy metropolitan hospitals with strict firewall controls or small doctor’s offices where many nurses are sharing a DSL line. It can also hamper Phase I and POC studies, whose short durations do not allow time to wait for the “IT guy” or telecommunications provider to set up a high-speed Internet connection.

Remedy and AdvantagesClinicians must be able to maintain full data com-munication using only mobile and/or low-speed connections without loss of performance, thus eliminating the need to rely on a dedicated high-speed Internet connection. The eClinical system must be designed to be fast and fully functional anywhere. By having mobile connectivity as an op-tion, sites can transmit data globally and have it

synchronized in real time, ensuring users are all working on the same set of clinical trial data. As a result, clinical staff members have a portable means to better suit their workflow by perform-ing data entry virtually anywhere in the field.

NOT BEING ABLE TO ACCESS ALL CLINICAL DATA WHEN NEEDEDAnother important concern of investigators, nurs-es, monitors and DMs is having a more efficient process when accessing needed clinical data. They don’t want to jump from system to system to gather the relevant data to complete their appointed tasks. According to an eClinical Forum study, 67% of re-spondents said access to all clinical data, including laboratory data and patient reported outcomes, via a single portal was important8. As a result, users prefer data remain in one system as it moves through its life cycle—from design to capture to coding to management to reporting.

Remedy and AdvantagesWith a cloud’s on-demand and globally available capabilities, all users work from the same data, at the same point in time regardless of role or loca-tion. This empowers investigators, monitors and DMs to capture and clean data more efficiently by enabling them to work globally from real-time data. The data remains in one system as it moves through its life cycle and should not move back and forth between different systems (incurring rec-onciliation costs and delays!) as occurs with “inte-grated platforms.”

With investigators, nurses, monitors and DMs working from the same data from a single source at the same point in time, re-work caused by in-complete or out-of-date insight into clinical data is avoided. Thus, monitors need not frustrate sites with queries on hours-old data for issues that may already have been successfully resolved.

CHOOSING BETWEEN CLEAN DATA AND FAST DATA There have been discussions that sites and study teams must choose between clean data and fast data. Site experience with traditional EDC systems certainly bears that out. Sites often report they are unable to clean the data at peak times like data loads and DBL. If they “can’t clean upfront” with edit checks and at fast speeds, they are doing re-

Page 6: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

6

ley Childs, global head of systems operations at Cmed Technology. “Clinical and lab data are still maintained on one server in a single far-off data center.”

According to Childs, Timaeus also has a mobile offline capability that works over low-bandwidth GSM/GPRS cell-phone networks. “As soon as con-nectivity is established, the mobile appliance repli-cates all data back to the server—just like your BlackBerry does when you get off an airplane,” he said.

James Haughwout, Vice President of Commer-cialization and Operations at Cmed Technology, explains that sites don’t want siloed databases; they want to access all their clinical data when needed. Timaeus provides this ability. Behind-the-scenes shuffling of data between different systems necessi-tates a complex and costly integration project de-pendent on data interchange standards that are themselves in a never-ending race with next-gener-ation technology10. “Murphy’s Law is never truer than when four systems attempt to talk to each other and the out-of-sync data flows incite yet an-other layer of IT conundrums,” said Haughwout.

Additionally, many EDC systems limit the num-ber of per-page edit checks and may even charge sponsors extra for surpassing that figure, stated Haughwout. Timaeus can render pages and apply edit checks in fractions of a second. Users experi-ence nearly instantaneous page turn and save times and, even via the Web, speeds of under a second are the norm, he added.

Cmed Technology and its sister company, Cmed Clinical Services, a full-service contract research organization (CRO), have collected data about Ti-maeus’ upfront data cleaning process. “Due to Ti-maeus’ ability to conduct more upfront validation checks during the EDC stage, and by amending traditional workflow, clinical data is much cleaner earlier in the process,” notes Dr. Andrew Griffiths, chief operations officer for Cmed Clinical Services. Griffiths added that research conducted with this streamlined model also confirm solid benefits in later stages, including a reduction in field monitor-ing work.

CONCLUSIONThe pain sites are experiencing with traditional EDC systems is unacceptable. The paradigm shift of how eClinical vendors are building and support-ing EDC systems is beginning to occur. Using

work and, ultimately, adding more time at the end of studies.

Some EDC vendors have to either limit the number of edit checks per page or turn them off entirely based on performance issues during high usage periods, such as when loading batch central laboratory data. Managing checks in multiple plac-es is a daunting task. For example, lab data that was viewable to the site physician may have failed a cross-page validation check that will be seen by the off-site DM.

Remedy and AdvantagesOne set of validation checks will work for data from all participating sites regardless of loca-tion—even when offline—and can scale through a cloud architecture to simultaneously support real-time manual entry from any site, anywhere and bulk loads by labs and DMs. A cloud-based plat-form encourages the use of more edit checks and more upfront data cleaning because it has the pro-cessing power for the job, making the choice be-tween clean and fast data an anachronism of the past. The ability to easily scale edit checks that work everywhere allows study teams to collabo-rate more efficiently, enabling the reduction in the number of queries that helps minimize re-work.

CAN SITES REALLY HAVE A GOOGLE-LIKE EXPERIENCE?Cmed Technology, an eClinical technology provider, has built an eClinical platform, Timaeus, to respond on demand to the needs of investigators, DMs and study teams from trial design through reporting. Cmed Technology states its architecture uses ad-vanced distributed cloud computing and mobile technologies to provide the freedom to manage any type of data, for any protocol, anywhere—with or without a high-speed Internet connection.

To avoid EDC sluggishness and eliminate serv-ers crashing, Timaeus follows the zero-downtime model spearheaded by Google, Amazon.com and Facebook9. They not only have distributed servers located throughout the world but also distribute their data. By doing so, the cloud approach enables them to avoid choke points by ensuring users are not trying to access content and data at the same time from only one database. “Some EDC vendors erroneously claim they can handle a global load, but the system slows or crashes because they dis-tribute just Web or application servers,” said Wes-

Page 7: Sites + EDC Does Not Have to = Pain · survey users want a faster login process and more than 40% want faster page turns from EDC sys - tems5. Simply logging in may be a five-minute

7

cloud and mobile technologies, EDC and eClinical vendors can respond to the pains of sites to:• Overcome slow EDC systems and servers that

crash, ensuring enhanced performance and speed with the computing load spread across different data centers around the world, elimi-nating congestion spikes, providing the ability to easily add to capacity and allowing zero downtime or 24/7 operation—even when modifying eCRFs and edit checks or perform-ing systems maintenance.

• Provide full data communication using mobile and/or low-speed connections so sites don’t have to be tethered to high-speed Internet connections, permitting study teams to per-form full EDC functionality in a regulatory compliant fashion.

• Enable all users to work from the same data, at the same point in time regardless of role or lo-cation, ensuring users have access to data as it is entered to avoid re-work caused by incom-plete or out-of-date insight into clinical data.

• Create one set of validation checks that works everywhere so clinicians don’t have to choose between clean data and fast data, allowing clean global data to be captured at all points quickly anywhere and at anytime so study teams can work more efficiently.

By giving site users a painless and positive Google-like experience, EDC becomes a trusted work partner. Something to think about: When was the last time your IT manager informed you your email system would be down for maintenance vs. the last time Google or Amazon.com was not available?

REFERENCES 1. D. Borfitz, “Investigative Sites: The Trouble with e-

Clinical Technologies,” eCliniqua, June 1, 2009; S. Redfearn, “Sites+EDC=Pain,” ClinPage, July 8, 2010; S. Redfearn, “Site Pain With EDC,” ClinPage, July 9, 2010

2. LinkedIn, Electronic Data Capture – Clinical Trials, “Sites+EDC=Pain” discussion

3. “2001: A Global Survey to Identify Investigational Site Needs Associated With EDC Trials,” conducted by Electronic Data Management Forum, Richard Per-kins; “2009: Revisiting the eClinical Paradigm: Inves-tigational Site Perspectives on Clinical Trial Information Systems,” data presented by eClinical Fo-rum at DIA, Richard Perkins

4. NIST “Definition of Cloud Computing,” Version 15, NIST.gov, October 7, 2009

5. “2009: Revisiting the eClinical Paradigm: Investiga-tional Site Perspectives on Clinical Trial Information Systems,” data presented by eClinical Forum at DIA, Richard Perkins

6. S. Redfearn, “Sites+EDC=Pain,” ClinPage, July 8, 2010; S. Redfearn, “Site Pain With EDC,” ClinPage, July 9, 2010

7. S. Redfearn, “Sites+EDC=Pain,” ClinPage, July 8, 2010; S. Redfearn, “Site Pain With EDC,” ClinPage, July 9, 2010

8. “2009: Revisiting the eClinical Paradigm: Investiga-tional Site Perspectives on Clinical Trial Information Systems,” data presented by eClinical Forum at DIA, Richard Perkins

9. “EDC Speed Burst,” ClinPage, December 14, 2010

10. D. Borfitz, “The New Normal for Clinical Develop-ment,” Bio-IT World, January/February 2011

About Cmed TechnologyCmed Technology, an eClinical technology provider, offers a unified platform for electronic trial design, paper and electronic data capture, monitoring, coding, data management and reporting. Its Timaeus eClinical platform has been built to respond on-demand to the needs of investigators, data managers and study teams. Timaeus’ unique architecture uses advanced distributed cloud computing and mobile technologies to provide the freedom to manage any type of data, for any protocol, anywhere. Timaeus has been used in every phase of clinical research—including early phase, pivotal and late phase studies as well as in globally established and emerging markets. A division of Cmed Group Ltd. since 2002 with roots from the University of Oxford, Cmed Technology has offices in the United Kingdom, United States and Romania. To learn how Cmed Technology is advancing eClinical trials in an on-demand world, visit www.cmedtechnology.com.