Figure 1: The Software Development Lifecycle
July 2002
Designing and Implementing Clinical Studies for the Internet
INTRODUCTION
When asked to write this article my colleagues and I felt that this was a great opportunity to help give clinical data managers an insight into life beyond paper based clinical trials. Those piles of CRF pages and paper or faxed queries can really become a thing of the past! Welcome to the 21st Century of clinical studies on the Internet.
DESIGNING CLINICAL TRIALS ON THE INTERNET
Most clinical trials go through the following stages of planning, start up, conduct (enrolment/recruitment of patients), close out and finally, analysis. In addition to this, Internet trials have a full scale Software Development Lifecycle (SDLC) built into the planning and start up stages of the trial. The SDLC is a complex application development process, normally followed by software giants such as Microsoft and Lotus and not usually a core competence of Pharma companies. Therefore staff with combined technical and clinical skills such as data managers will become key contributors to the future of e-clinical trials.
PLANNING STAGE
A project manager (PM) of an e-clinical trial must consider all current elements of a trial, including protocol design, patient recruitment planning, resources, tasks and training. In addition, the PM must now also manage the SDLC and adhere to formalised software validation and change order processes. The PM must assemble and manage a clinical design team with a much broader focus, including skills for clinical system design, application programming, server commissioning, equipment deployment and helpdesk support.
START UP STAGE
Clinical project managers, Clinical Research Associates (CRAs)/Monitors and clinical teams still proceed with activities such as site selection, drug supplies etc. However, now with Internet trials, the PM must also manage the activities, which are brought forward and must occur before the first patient even enters the trial. These include: edit check programming, testing, user training, commissioning sites, testing internet connectivity, provision of computer equipment and peripherals.
SDLC Step 1: Requirements
Designing clinical studies on the Internet requires detailed specifications. These specifications become part of the system validation documentation for your clinical trial. Table 1 shows the "Ten Commandments" of an Internet clinical trial specification.
Table 1: Ten Commandments" of an Internet clinical trial specification.
Specification Document Including
Protocol and example paper CRF Final version of protocol is essential. Example paper CRFs are useful, especially in first e-trial.
Electronic Case Report Form (eCRF) Design Form organization by visit, question order, question text, response formats, data types, and code values.
Database Design Database field mapping, field information, table structures, etc.
Data Import/Export Design (if applicable) Specifications for the automated exchange of external data, such as the loading of laboratory data into the appropriate eCRFs.
Automated Edit Check Design Edit check logic, ranges, query text, locations, test parameters, etc.
Automated Rule Design Calculated controls/variables, mappings across forms, email notifications, etc.
Rights and Roles A list of "rights groups" and the system rights enabled for each group of users.
User and Site Lists Site and user information, including site and rights group assignments for each user.
Miscellaneous System Configuration Settings Timeout parameters, login password expirations, date display formats, and other such parameters relating to general application behaviour.
User eDocuments eProtocol, eHelp (CRF Completion Guidelines) and Homepage specifications.
SDLC Step 2: Design
Once the specification has been accepted the design stage of start up can commence. The Internet clinical trial application has the following components e-CRF, edit checks, e-protocol, e-CRF help, and data import and export subsystems.
Designing eCRFs and edit checks is a balancing act between the needs of site users (investigators, study nurses) and the clinical team (CRAs, Data Managers and Statisticians etc). Site users need the system to be intuitive and easy for the hand and eye to follow and helpful in avoiding missing data or format errors. The clinical team needs to collect the right data to an adequate level of quality for the ultimate goal of analysis. Therefore it has been found that specially trained data managers, who design the eCRF and edit checks, can provide the balance between the design and performance needs of site users with the appropriate level of data checking required to provide clean data for analysis.
New roles emerge during the design stage. Database programmer and data manager, merge or specialize into the clinically focused 'clinical trials designer' (referred to above), who is responsible for the specification and design of clinical trials applications and a technically focused 'application engineer' responsible for programming the edit checks, and setting system configuration, and other sub-systems and testing.
We can exploit the use of HTML objects, commonly found in Internet browser applications, such as pulldown lists, radio buttons and check boxes, to improve the collection of data. So, where in the past investigators may have omitted data on paper CRFs, they can now be assailed by multicoloured flags that alert them to missing or incorrectly entered fields. Figures 2-5 are examples of how HTML objects can be used to efficiently collect clinical data.
Figure 2: Pulldown lists used to control entry of erroneous data into dates and times. Pulldowns can prevent Month/Day confusion or year pulldowns can be used to prevent entry of patients outside the age limits of the protocol.
Figure 3: Here you see the warning message encouraging the user to enter data of the right format into the entry field. This type of check can be used to apply strict ranges, which prevent entry of data outside the range.
Figure 4: Check boxes can allow the entry of multiple responses such as the family history questions.
Figure 5: Radio buttons can prevent the entry of more than more response to a question. Here you can see that a common dilemma facing many paper CRFs is eliminated with intelligent CRF design. Previously selected radio buttons, deselect upon selection of a new answer.
The examples shown in these figures can enormously improve the validity and cleanliness of data collected at site and reduce the huge, retrospective paper effort of data cleaning using edit check programs run in batch and reviewed by data managers.
The next major design task is the specification of edit checks. The examples shown are "hard" or "browser-side" edit checks, built into the screens that activate immediately upon entry of data. The second types of check are called "soft" or "server-side" edit checks. These allow entry of data outside limits or ranges after responding to a generated query. The queries fire after the user hits the submit key and the data is transmitted to the database application.
SDLC Step 3: Coding/Programming
In non-programming terms this is the bit that the boffins go off and into a darkened room and program hundreds of lines of code in order to make your application do what it's supposed to do! The new role of application engineer takes the eCRF application and adds functionality to it by programming edit checks and other features. In most Internet applications this takes place in visual basic or C++.
SDLC Step 4: Testing
The application engineers apply "unit" testing to discrete programs, and "integration" testing to the whole application, after they complete coding or "build". Testing is normally iterative, meaning designer and engineer work closely to optimise specification, design and programming to resolve any human errors or changes in the protocol.
There are normally several more steps that include Quality Control, independent Quality Assurance and finally but not least, User Acceptance Testing (UAT). The UAT has a major impact on sponsors unfamiliar with e-clinical trials, as this requires them to "road test" the application and after they are satisfied, approve it. Again data managers normally play a key role in the sponsor UAT.
SDLC Step 5: Implementation
Tasks such as site assessment, equipment provisioning, server build and commissioning and user training complete during the final stages before the trial enrolment starts. Internet servers are built and housed in secure facilities and helpdesk infrastructure is implemented. User lists are provided to assign users to the correct user groups.
Before a user can access the system, they must be trained in its use and activated by system administrators. Upon final approval by QA and the User Acceptance, the trial can finally be released for use or "go live".
CONDUCT/ENROLLMENT STAGE
Several new processes kick in after patients start being enrolled into the study and being entered into the Internet application. These include: change control to fix edit checks or design issues that emerge during real-life usage; server maintenance and tuning to help keep server performance optimal; multilingual helpdesks available to support users who have questions, or may even have just forgotten their passwords! It is also necessary to introduce technical support teams to troubleshoot bugs that may emerge during this stage of a trial.
Impact on Traditional Roles
Due to the effort of building the eCRF and edit checks when designing the trial, the data managers have much less data review to carry out during the conduct of the clinical trial. Therefore they can focus on the efficient and proactive review of data accumulated on-line during the trial and of course its quality.
The CRAs can focus on building investigator relationships, efficient trial management and data quality. They can review data remotely before even visiting sites and they can plan their monitoring visits to maximum effect.
End users such as investigators, study nurses, study site coordinators are particularly affected by EDC. Their day-to-day clinical trial experience will now include entry and query resolution. Investigators do find the data entry a burden, and often will delegate this work, as in the case of paper CRFs, to study nurses to do. However the Investigator/CRA relationship is improved as they become jointly responsible for the resolution of the queries presented in the EDC system.
Data Visibility
One of the biggest impacts of an effective e-clinical trial is data visibility. Those who are familiar with waiting for data listings or reports from traditional clinical database are often frustrated, due to delays in collection, entry and querying of the data. Data visibility will be one of the startling changes your first Internet trial can bring.
Investigator and study site staff will find that the user interface is generally helpful and friendly. Querying exists normally in the same subsystem as the eCRF and visual cues such as icons or colours help represent the status of data (e.g. green traffic lights for complete data, snowflakes for "frozen" status) and help the clinical team assess progress. This "point of entry" cleaning and interactive help and documentation are again key factors in the success of current e-clinical trials with investigators.
CLOSE OUT/ANALYSIS PHASES
It is true that Internet clinical trials can speed up the conduct stage of a trial and hence make the database lock and site close out, less painful. However, this is only achieved with the buy in of the whole clinical team and exploitation of the advantages offered by the internet such as data visibility, point of entry cleaning etc. Database lock time can be reduced with regular review and monitoring of the data volumes and quality. The regular download of data to statistics can help in the earlier, ongoing development of analysis programs and thus lead to quicker analysis.
Statisticians, Medical Writers and Drug Safety Scientists can all benefit from the concept of data visibility. Given read access, they can view real trial data without disturbing the entry and cleaning of that data.
SUMMARY
Certainly the first experiences of the Internet can be an intensive learning and can be fraught with issues. However with appropriate control and planning, they can be very successful. The ultimate benefit should be that we could channel competent staff such as data managers into proactive roles rather than the retrospective focus that the paper world gives us.
Many types of Internet software are available from a number of EDC vendors. The initial costs of such systems should be balanced against the return on investment, if only from a data management perspective! Cost savings introduced through the elimination of paper CRFs and queries, tracking and data entry should not be underestimated.
Initiatives such as CDISC and the increasing use of company data standards will also change how we exchange and provide clinical data. So let us embrace Internet trials and data standards and make those piles of paper go away!
Adam Baumgart
Director of Clinical Services, Phase Forward Europe Ltd