Planning an EDC Clinical Trial

Using electronic data capture (EDC) for your clinical trials creates a few more things to consider than when planning a paper-based project timeline. Perhaps youve used this type of data collection system in the past and you have the lowdown on the who, what, when, and wherebut, just in case you dont, here are some tips on making this new method work for you.

Managers of clinical studies know the basics of project planning: finalized protocol and case report forms (CRFs), selected sites, completed and approved regulatory documents, completed project timelines with all the assorted sundries that can ensure the success of our projects. And, if were lucky, well have all the grants approved and contracts signed.But, with the EDC component, what else do you need to consider? EDC isnt quite as easy as stopping by the cybercaf, logging on, and sending an e-mail (although it seems that it should be, particularly when you can instantly send text messages to anyone around the world). Why is sending clinical data as bits and bytes over the Internet so different? Why cant we just plug and play?

For starters, youll need to assist in the writing and approval of the various EDC components that will be integrated into your project plan. For example, the EDC vendor may have a form called a Systems Requirements Specification (SRS)a document that contains information about the study and the way the electronic case report forms look and interact with one another. These requirements will be tested by the developers, sent to formal testing, and then to you for user acceptance testing.

My first thought when I get any new project is, How can I make my project life as uneventful and stress-free as possible? I try to figure out all of the things I can control, because you and I both know that even with all the planning, it seems that Murphys Law will prevailanything that can go wrong will go wrong. So incorporating project planning that includes EDC timelines and other components that affect the operations will make for a more successful project.

IQ/OQ document. One of the beginning steps is for the EDC vendor to supply you with its Installation Qualification/Operations Qualification document, referred to as their IQ/OQ. This important document states the hardware requirements a computer must fulfill to run the software successfully. If the sites cant meet the minimum requirements, they will be unable to use the EDC software. This is no way to start a project. (Trite as this may sound, the success of this enterprise begins at the site. The use of EDC is in a transitional stage.) The newer generation of clinical professionals wont be as tied to paper processes as their predecessors, because of their experience with computers, personal digital assistants (PDAs), and various types of wireless communication. Right now, however, many of the participants in the electronic revolution are not necessarily volunteers, so the people using this technology may not be embracing it so much as tolerating it. To minimize frustration at the site, a site assessment is crucial.

Site assessment. For the site assessment, we have to look at the small and what may seem to be obvious details.

• Does the site have a computer?
• Do the investigators and study coordinators understand how to use a computer?
• Do they have a modem?

As for the sites Internet connectivity,

• Does it have Internet-dedicated phone lines or do they have to share lines?
• Does it have high-speed connections?

Gleaning the answers to these questions can pay off in many ways. For example, youll know which sites may need additional assistance in using the EDC software. Knowing this can help you plan appropriately. You may be able to set up sites in groups to assist with basic computer support.

If the site has information technology (IT) support, youll want to meet with the support person to discuss the software to be used to collect clinical trial data. Get tech support persons involved up front. They can make your life easyor they can make it difficult. Youll need them to resolve firewall issues, for example, and to let you know when/if they are going to add or delete software and/or upgrade the computer to the latest and greatest standard mandated by the hospital, university, or clinic. When an upset person from a site calls you about not being able to get into the system or to say its not working right, having a technician in the know at the site can go a long way toward alleviating problems. These are small things that you can do up front to prevent headaches later on down the line. Some of you know what Im talking aboutyou have lived on the new frontier of data capture!

Software compatibility. Once you ascertain some of the basics, check to see whether the vendor knows of any incompatibilities with other software programs that may affect the use of their EDC application. It is similar to learning about drug reactions. If you know that a particular drug has a known reaction to another drug, you have choices: You can choose to avoid the drug or to take it because you know the benefit of taking the drug outweighs the risks of the reaction caused by combining the two drugs.

Similarly, to avoid serious adverse reactions to EDC, you will want to know up front of any potential risks so that you can weigh them against the benefits. Note of caution: You may find that additional compatibility issues arise once EDC is rolled out to your sites. That situation is similar to the moment when we say, Oh [expletive deleted], I didnt think of that about a project for which we were certain that every contingency was anticipated. A similar event can occur when hundreds of thousands of people are taking an approved drug. With so many individual variables involved, a new problem can be uncovered. So it can be with EDC.

Quite frankly, I think the site is one of the most important areas on which to concentrate.

• What do site personnel know about EDC?
• What types of experiences have they had using new tools to capture data electronically?
• Do they see value in using EDC?

One thing I find useful when planning a site evaluation visit is to take a demo version of the product to show the site. That way you can have a hands-on session early in the process. Another area to consider is whether they are willing and eager to accept change. If not, you may have a problem. If you thought your life was miserable calling the sites and badgering them about recruitment, just wait until you add the machine to the mix.

Setting up eCRFs. During project planning, in tandem with the EDC vendor, youll be planning the actual creation of the electronic case report forms (eCRFs) to capture the data electronically. What this does for us is get the edit checks and database set up, prior to study rollout and first subject in. The effect of building the eCRFs early in the study is that database setup is part of the process. As the electronic data elements are defined and added to forms, the database setup is expedited because defining the forms also defines the database. Once the electronic study goes live, by definition, the database must be up and ready to start receiving data.

One of the many beauties of EDC is that the database and edits are built up front. The CRFs will be in an electronic format that will have edit checks programmed in, with annotations if so desired. So when data comes in, you know that the first pass of data cleaning has been done with the automated edit checks. The CRA and data manager can write queries, the applications audit trails record all the changes to all of the data fields, and preliminary reports can be run. When I was a project manager, that was the one area that I could let slide. It is important, but when push came to shove (and it often did), edit checks and databases could be built once the sites were up and enrolling. Even though we knew we would find ourselves in a data crunch, it always seemed we were willing to take our beating later. Those data safety monitoring meetings seemed so far in the future!

Study requirement specification. When you plan your project, it is imperative to plan time for EDC. This means that you and the software developers will work closely to complete several stages of the project. You will define the project. They, in turn, will prepare their project plans with deliverables for both sides. They will work with you to define the initial study requirement specification (SRS), the functional requirements, edit checks with the visit-screen structure, and other information regarding issues such as back-up and recovery. The development of an SRS may take a week or two depending on the type and complexity of the study. The software vendor needs to have final copies of CRFs to build the study accurately.

I cant stress enough the need to pay attention to the SRS document. You must spend time with this document, and make sure it is complete and accurate. Otherwise, a visit to Heartbreak Hotel is in your future.

First, the software company may have policies that prevent them from beginning work on the trial software until they have an approved and signed SRS. Their time to complete this stage of the project begins then, not before. So when they tell you, It will take approximately six weeks, they usually mean six weeks from the date they have a signed document from you. Once they build the study application, then they do unit testing. This is a first pass to make sure that everything is working as designed. They then send it to their formal testing team where it goes through more rigorous testing to ensure that every requirement in the SRS is exercised and functions as designed.

Once it passes formal testing it is sent to you and your team for user acceptance. If you and your team accept the application, wonderful; its time to start rolling it out and entering data. If not, it is sent back to the developers to fix whatever your team deems necessary. The developers make the changes and send it back to testing. Again, the testers do the formal testing, then send it back to your group for user acceptance. The cycle goes on until the application is completed to the users satisfaction. (A note of caution: If, during development, a specific investigator requests an additional case report with lab data, that request constitutes a change to the originally signed SRS, and it will probably be considered out of scope. The predictable result is an increase in your study budget and a rollout delay.)

You will have the opportunity to review and accept the SRS. Its a good idea to have biweekly meetings and status reports to make sure that everyone is on the right path. Remember that EDC vendors have expertise in design but not necessarily in the nuances of a clinical trial. I have never seen an SRS redone a million times over, but I have seen one go several rounds. This can be attributed to several factors, but the bottom line is this: If you dont understand something, ask. If you change your mind or want something changed, it isnt a one-step process. Communicate with the EDC vendor. Plan appropriately to incorporate the time to define, build the study application, test, and approve it. Once the software is accepted, it is time to plan for site rollout. This can be accomplished many ways depending on the software you have purchased. Is it Web-only or is it an online/offline system? The vendor will either push it out to the sites or ship CDs to the sites for installation.

The location and number of sites will determine how quickly this task is completed. Once this is accomplished the sites can start to enter the data. Edit checks will pop up, the site will answer them, and CRAs will post queries as often as they need to. They can see the data in real time, and you are on easy street. Youre getting the data, the reports are being viewed, and everyone is wondering why it has taken usor is taking usso long to adopt EDC.

Setting priorities. I know you have difficult jobs; Ive been there. We have to decide what must be done to start a project on time, and what must wait. Working with the hardware and software of the technology world, techies sometimes forget that clinical professionals dont work with widgets, they work with people. It sometimes amuses meand is sometimes downright frustratingwhen technologists think that they can line em up and knock em down and wonder why cant we do the same.

But we work with people and institutions; we need to take in all aspects of human behavior to do our jobs. When I get frustrated, Id love to just turn off my machine, put it in sleep mode, or go dark. But we cant do that with subjects. We have to continuously work through the problemswhether they involve site recruitment or the nuances of this new tool, EDC.

With the right planning, education, and training we will all be able to have a positive impact upon our studies. EDC is a wonderful tool, but it is up to us to work with the vendor and plan our project timeline appropriatelynot just at the beginning but through every stage of the project life cycle.

Donna Hellsten*is vice president of Global Client Services, CB Technologies, Inc., 350 Eagleview Blvd., Exton, PA, (610) 280-7400, fax (610) 280-0440, e-mail: d_hellsten@cbtech.com. Christopher Dell is marketing support manager for CB Technologies, and Karla Beckner White, who also contributed to this article, is associate manager, public relations.

*To whom correspondence should be addressed.