Jean Paty, PhD, is the founder and chief quality officer of invivodata, inc., 2100 Wharton Street, Ste. 505, Pittsburgh, PA 15203, email: jean@invivodata.com, Web site: www.invivodata.com.

Jean Paty

I cannot believe FDA did it again. For two years in a row, FDA comes out as the leader, pushing our industry forward. At the end of 2010, we thanked FDA for encouraging us to listen to the patient. This came through loud and clear in FDA's publication and promotion of their patient reported outcome (PRO) guidance at the end of 2009. PROs are direct reports from the patients that are not interpreted by a health professional. The propagation of PROs across product development programs, and the appearance of new PRO-based labels in the past two years is clear evidence we in the industry are hearing FDA's message. 

 In 2011, FDA went yet another step by telling us that there are multiple ways to give the patient a clear voice in clinical research. Specifically, FDA stated that we need to ensure all of our measurements and outcomes, not just PROs, reflect what is happening with the patient. In other words, we need to provide evidence that all of our instruments or tools measure what we think they measure. In FDA terminology, we must ensure that instruments or tools and their related outcome measures are fit for purpose in their context of use.  

Specifically, this means that instruments based upon a clinician's evaluation of a patient (ClinROs), and measures taken by an observer (ObsROs), like a mother reporting about her child, are subject to the same requirements for reliability and validity as PROs. FDA expects that all outcomes assessments (OAs)—ClinROs, ObsROs, and PROs—will meet 21CFR314.126(b)(6) requirements that "the methods of assessment of subjects' response are well-defined and reliable." The recommendations of how to meet the well-defined and reliable standard are delineated in the PRO guidance. In other words, FDA is using the PRO guidance as the yardstick by which it measures all OAs. 

The announcement regarding OAs came during an FDA-sponsored workshop held on October 19, 2011 at the FDA White Oak Campus in Silver Spring, MD. Both FDA and the industry were represented at this one day workshop. Janet Woodcock, MD, Director of the Center for Drug Evaluation and Research, gave the opening address and set the stage for OAs: 

 "Now clinical trial outcome assessments are one type of drug development tool that we have identified as ripe for improvement. The identification, development, and qualification of new clinical trial outcome assessments is an area that has really not been aggressively pursued by the scientific community, and the lack of—the consequent lack of assessment tools has been impeding, I think, the successful development of new drugs because we really in many cases don't know how to measure the impacts, both for good and ill, of the drugs that we test in people. And we can do better." 

This challenge from Woodcock also provides opportunity. OAs that are well-defined and reliable can support novel labels for our products, which in turn differentiate them from other treatments. There is now a defined regulatory pathway to novel product labeling. 

It is refreshing to see that regulators are prepared to help us in the industry meet the challenges of bringing new products to market, and most important, to create a pathway of success for these products. What do you have planned for 2012, FDA? 

, Senior Vice President, invivodata, Inc. 

Articles

All measurements and outcomes need to reflect what is happening with the patient.

Give the Patient a Clear Voice

Subject diaries are used  to collect primary and secondary endpoints in about 25% of all clinical trials.1 In recent years, the traditional paper diary booklets have been replaced in some instances by small electronic devices for recording diary information.2 Our series of articles is aimed at helping clinical researchers understand the development, implementation, and regulatory compliance of these electronic patient diary systems. Our particular focus is on the reasonable apprehensions expressed by clinical teams considering whether to use electronic diaries. They worry about these issues.	

Lack of clarity about complying with the regulations governing electronic systems (discussed in Part 2)

Lack of knowledge about how an electronic system is specified, built, and deployed

The effect of including an electronic diary in the clinical trial development process and timelines

The number of work process changes that could be required of participants in the clinical trial process: sponsor staff, monitors, investigators, and subjects. 

To address these concerns, this series presents the clinical, technical, and regulatory issues involved in the development and implementation of electronic patient diary (EPD) systems that meet regulatory requirements. Part 1 compared paper and electronic methods in the context of existing FDA and ICH regulations and guidance for capturing diary data.3 We concluded that newer, electronic methods are in fact more compliant with FDA and ICH data standards than traditional paper diaries. In Part 2, we began discussing the clinical and technical considerations for developing an EPD system. We focused on the clinical protocol and its definition of the medical moments-the health experiences-to be recorded by the subject, and we concluded that it is key to the success of an EPD system.4	

In Part 3 we discuss the development and validation of an EPD system based upon a clinical protocol. As shown in Figure 1, a computerized EPD system extends beyond the hardware and software used by the subject. It also includes the systems components and work processes for all users of the system; the core of the EPD system is the diary device containing protocol-specific software. The device also requires some type of communication software and hardware-for example, a peripheral wired modem that connects to a regular phone line-to transmit the subject data to a central data repository or server.	

Figure 1. Computerized system for electronic diaries.				

Once it is on the server, the subject's data can be processed and viewed in a secure environment by those responsible for trial management and conduct. The investigative site can use this information to evaluate the subject's compliance with protocol procedures. The sponsor's clinical team can review the data from the server to monitor the investigative sites' activities and to assess the subjects' performance. The components of a successful EPD system include the activities carried out by the subjects and the trial managers as well as the hardware and software. 	

The key players in developing an EPD system are the clinical team responsible for the trial and a technical team that brings the EPD technology and the expertise to customize the technology for a particular trial. To design and develop an EPD system that meets the needs of the protocol takes close collaboration between those two teams. Many aspects of the collaboration should be familiar to the clinical team, given that every trial requires a well-coordinated effort between the sponsor, CRO (where appropriate), investigative sites, and subjects.		

Unique features of the collaboration of the clinical and technical teams are the development of the EPD technology and the support structures-training materials, for example. This development, however, should be greatly facilitated by the technical team's expertise. The result should be that the experience of developing an electronic diary system and then executing the trial in which it is used should feel much like that of any trial for a clinical team. 	

A successful collaboration of the clinical and technical teams depends upon clearly defined responsibilities, tasks, and deliverables. Figures 2 and 3 diagram the tasks required to develop, implement, and eventually retire an EPD system in the context of a clinical trial. Figure 2 illustrates the system development life cycle (SDLC), activities primarily driven and executed by technical team. Figure 3 depicts an EPD clinical trial life cycle (CTLC), which summarizes the activities and support structures needed, mapped onto the typical steps involved in planning, launching, executing, and closing out a trial. CTLC activies are driven by the clinical team and executed through collaboration of the clinical and technical teams.	

In Part 2 of this series we discussed Steps 1 and 2 of these life cycles, the development of a clinical protocol and the user requirements specification (URS) for an EPD system. Assuming a clear set of specification documents for the system, we focus here on Steps 3 through 6 of the SDLC and CTLC, or the preparation of EPD system for trial launch. The two streams of activities that occur during preparation are the building and testing of the EPD software (SDLC), and the development of all of the support infrastructures for the software (CTLC). 	

Details of the tasks, responsibilities, and deliverables at each step are described below. As in any GCP study, an essential component of all of these activities is careful and clear documentation of the process. Figure 4 diagrams the computerized system validation (CSV) documentation that results from this documentation. The outcome of Step 6 in the system development life cycle and the clinical trial life cycle (diary acceptance) is a validated electronic diary system that performs as intended.	

Infrastructure (Paty, clinical-regulatory) Once a protocol is approved, the clinical team begins to establish the infrastructure for the study. This includes selecting a CRO, if one is to be used, and sites for the study. The sites do not need to be technically proficient if the EPD system is designed with end users in mind. In our experience the most important site qualifier is willingness to learn something new. Of course, if the site has previous experience with an electronic diary system, this can significantly aid the implementation of the trial. For many EPD systems, the infrastructure requirements for sites are minimal: a regular phone line and Internet access. 		

Figure 2.  The System Development Life Cycle (SDLC).				

Equipment selection and purchase is another component of preparing for an electronic diary system. With the technical team's advice, the clinical team makes the final decision about the hardware best suited for the subject population being recruited for the trial. Subject hardware includes the data collection device and possibly communications hardware (an attachable wireless or wired modem, for example). 	

Investigative sites may need specific hardware to support the system, but for systems that rely on the Internet, sites may simply require Internet access and standard browser software. The same applies to the sponsor and/or CRO staff. For global trials, the subject hardware selected needs to support multiple languages. Communications device needs may differ from country to country given variability in wired and wireless capabilities in Europe, Asia, and South America. Once the hardware decisions are final, early procurement ensures that equipment is not a bottleneck in developing and launching the trial.	

Diary design (Stokes, technical-regulatory). Steps 1 and 2 in the EPD system development life cycle translated the clinical protocol into a user requirements specification (URS). The technical team's first action in diary design is to translate the user's view of a diary (their URS) into the functional requirements specification (FRS), a technical document that describes the EPD system in a way that a programmer knows what has to be built (Figure 2, Step 3). To maintain the integrity of the original protocol throughout the validation of the electronic diary, the technical team creates a traceability matrix that links the requirements in the protocol to those in the URS and then to the FRS. The traceability matrix has a central role in ensuring that anyone can begin with the protocol and trace through all of the documents to ensure the system was built as specified. 	

Traceability matrix. It is important to create a traceability matrix showing how the URS addresses the Protocol sections and how each and every URS statement is addressed by one or more FRS statements. Here are some examples of protocol statements with corresponding URS and FRS statements.	

Protocol statement (from clinical team). "Weekly Assessment: The following question will be assessed approximately every seven days during treatment period as part of the subject's daily assessment . . ."	

URS statement 24 (from clinical team). Flow chart made to show Q&A dialogue for daily assessment and also the insert prompt for a weekly summary assessment.	

FRS statement 53 (URS 24) (from technical team). Screen prompt question is "Answer the following item according to how you have felt during the past week." This prompt and subsequent dialogue is to show in the EPD on study days 7, 14, 21, 28, 35, 42, 49, 56, 63, 70, and 77. 	

The system design description (SDD). In order to tell the programmer how to build the diary, the technical team converts the FRS statements into a system design description (SDD). Usually a design description statement covers more than one FRS statement. Thus, an item-for-item traceability to the SDD is not useful, but an overall system design review should be performed to ensure that all the FRS statements have been covered somewhere in the system design. Taking the FRS example described above, the appropriate SDD statement (from technical team) would be		

Figure 3. Electronic patient diary clinical trial life cycle (CTLC).	

Code the system with a study-day tracking variable (variable SD4) so that the EPD tracks the current Study Day number. Code the Daily Assessment to always check variable SD4 whenever it is called in the code and to check if the Study Day (SD4) is day 7, 14, 21, 28, 35, 42, 49, 56, 63, 70, or 77. If Study Day matches, then code system to display extra dialogue item as per UR24. If no match is made, then code so that no extra display is issued to the EPD user.	

The process of moving from protocol through to functional requirements and software design is usually an interative one. It can be readily accomplished with consistent and effective communication between the clinical and technical teams. After several EPD trials, when the clinical team learns the capabilities of the technology, it can refine the protocol statements to more easily translate into functional requirements. The technical team can then develop standard diary modules and the whole EPD development process becomes faster and more efficient.	

Software review, training, and plans (Paty, clinical-regulatory) With the sites selected and the technical system specifications written, the clinical team-with considerable support from the technical team-can focus on planning and implementing various components of the EPD system. They can				

Review and approve EPD software prototypes 

Develop a plan for deploying units during the study.

Software review. A very important component at this stage of development of the EPD system is a clinical team review of alpha (early stage) software. This review allows the clinical team to determine whether the technical team is developing software that accurately reflects the protocol. Most important, it is an opportunity for the clinical team to determine whether the software is "coming alive" in the way they had expected. If it is not, this is the time to pause and reconsider the design of the system and its specifications. When the clinical and technical teams collaborated during the specification process, the typical outcome of the alpha review is making only a few minor changes to the system.	

Training materials. In an EPD study, concise and clear training is essential for all users of the system. 21 CFR 11.105 states that persons using an electronic data capture system need to be appropriately trained on the system. Training materials need to be developed for the different user groups-subjects, the investigative site staff, sponsor/CRO clinical research associates (CRAs), and other study management staff. The technical team often provides a core set of training materials that are customized for the specific trial. The customizing requires knowledge of the protocol and the system, suggesting a clinical-technical team collaborative effort. 	

Help desk. Another component important to the planning of an EPD trial is a plan for a technical help desk that will support the study. The clinical team's input is important here, because the technical help desk will be dealing with the subjects, the investigative site personnel, and the CRAs. As such, help desk personnel will need to understand how to address technical issues that may be specific to the EPD protocol. The technical team provides the technical details, and the clinical team provides protocol-specific content. That content is then reflected in scripts for the trial that guide help desk personnel who respond to questions from the trial participants. In multinational trials, the scripts can be developed so that they can be readily translated to all relevant languages. Implementing the scripts and general management of the help desk is typically the responsibility of the technical team.		

Figure 4. Electronic patient diary computerized system validation (CSV) package model.	

Equipment deployment. The clinical and technical teams will plan the provisioning (loading software onto the EPD units) and shipping of equipment to investigative sites. Their plan needs to take into account the exact provisioning process, who will perform the activity, how and when units will be shipped to sites, and the timing for returning units from the investigative sites. Given that some trials are conducted with thousands of subjects in several countries, a well conceived plan for provisioning and shipping is an important component of trial preparation. The clinical team will provide input based upon knowledge of the sites' locations, and the technical team will delineate the process and manage the provisioning and shipping process. 	

Data management. The data management and statistical groups may begin their planning at this point. Based on the database design described in the specifications, the sponsor-CRO data management team can work with the technical team to ensure that the method and format for delivering the data is clear. This will ensure that data can be delivered regularly to the sponsor or CRO for inclusion in the clinical database. 	

CTLC Step 4 summary. Once the planning, development, review, and approval activities have established the support stucture for an EPD study,	

the materials are prepared to train the system users.

the plan is in place to support the users if/when they have questions or problems.

the plan is in place for getting the EPD devices to sites for subjects.

the plan is in place for delivering data to the sponsor.

The clinical team is ready to initiate sites for the trial, hold the investigator meeting, and launch the study. 	

The study protocol and a set of specifications are the road map for developing the software and the support structures for an EPD study.

Author | Jean Paty