Use Case and Application Requirements for a Protocol Lifecycle Tracking Tool, with a Focus on the Trial Initiation Phase

Abstract

The time required to initiate clinical trials, from declaration of the investigator’s intent to opening of the study for participant accrual, is cited as often being so long that clinical research is seriously impeded. Efforts to improve operational efficiency of trial initiation are confounded by the work flow complexity and the variations encountered with different types of trials and institutional environments. A computer Protocol Lifecycle Tracking (PLT) tool would enable study initiation staff to manage the process, and the various clinical research stakeholders to monitor the progress of a study’s initiation, as well as obtain data on the work flow to identify those activities that are in need of operational efficiency improvement. The objective of our work was to develop use cases and system requirements for a PLT tool. The result of our study is a use case document that can serve as the specifications for developing a PLT application.

Introduction

A 2005 report on restructuring the cancer clinical trials enterprise stipulated the reduction of operational barriers to trial initiation among its primary goals.1 Supporting the significance of trial initiation delay, Dilts and his colleagues, who have uniquely studied these processes involved in opening trials, concluded that in some situations “The steps required to develop and activate a clinical trial may require as much or more time than the actual completion of a trial.”2 Another Dilts study, which evaluated the trial initiation processes at a major academic medical center, noted that while administrative barriers to opening trials is often criticized by researchers, the process has in general not been formally documented or evaluated.3

The sometimes long delays in activating clinical trials, as well as the conflicting anecdotal attributions for these delays, are well known to those involved in clinical trials research. Correspondingly, comprehensive means for monitoring the work flow of study initiation by the various stakeholders – principal investigators, clinical research associates, administrators – are not available. To address this, we have undertaken the development of use cases and system requirements for a computer Protocol Lifecycle Tracking tool, which would not only provide the capability to manage the process flow and monitor the progress of trial initiation in real time, but also deconstruct the complex work flow and provide institution and study-type specific data on the contributing factors to initiation delays.

Background

The National Cancer Institute’s cancer Biomedical Informatics Grid (caBIG^®) program, begun in 2004, includes clinical trials research informatics among its primary domains for investigation. The caBIG^® Clinical Trials Management System (CTMS) work space has created a Business Architecture Model (BAM) of the clinical trials research work flow, from study initiation, through study conduct, to study closure.4 The BAM describes the activities, goals, people, and organizational needs involved in clinical trials. The almost 400 pages of use cases developed for the BAM informed CTMS participants of the variability and complexity of the clinical trials work flow: the activities involved in planning, initiating, and conducting trials varies according to the sponsor (industry, government agency, cooperative group, or institutional investigator initiated) and whether the sponsor (e.g., cooperative group) or performance site (e.g., cancer center) perspective is being considered; whether the trial is interventional or non-interventional; and the specifics of the trial itself (e.g., pharmaceuticals or device involved?).

With this comprehensive BAM to draw upon, we decided to develop the use cases and requirements for a Protocol Lifecycle Tracking computer tool that could accommodate the inherently variable work flow of initiating clinical trials research. So while the caBIG^® BAM describes the clinical trial processes, this PLT use case project describes the requirements for a tool which can manage these processes. Furthermore, while this study arose from the caBIG^® program, non-oncology clinical trials expertise was also included for these specifications, to minimize disease-specific applicability.

Methods

The objective of this study was to define the functional requirements for a Protocol Lifecycle Tracking (PLT) tool. While the activities of the trial initiation phase was the focus for this requirement gathering, it is felt that the tool capabilities for this lifecycle phase will probably satisfy the needs of the subsequent trial conduct and closure phases, although this cannot be said with certainty until these later phases are further evaluated. But for this study, the conduct and closure phases were out of scope.

To gather the functional requirements for the PLT tool we employed use case systems engineering methodology.5 The use cases describe the system processes and actors involved in the use of the PLT tool. It should be noted that the use cases are for the PLT tool – not for the clinical trial initiation work flow that is being monitored by the PLT tool. Thus the actors consist of clinical trial study personnel who use the PLT tool, including coordinators, managers, and PLT system administrators.

Use cases can vary in the degree of detail they capture. Also the structural form of a use case can vary, but certain elements are always included. These basic use case elements are a name, brief description of the use case’s purpose, a summary, or “storyboard,” giving an overview, a list of actors involved, the pre-condition describing the system state required for the use case’s deployment, the flow of events, and the post-condition describing the system state after the completion of the use case.

Use cases stipulate what a system must do, but not how it is to be done. Software development teams can use the use cases to define the end user functionality of the system they are coding, but they are free to employ whatever methods they choose to implement that functionality. For example, the choice between employing thick or thin clients for an application would not be directed by the use cases. However a gray area in this distinction between “what” as opposed to “how” is the degree of user interface detail that should be included (if any) in use case definitions. End users are more directly affected by an application’s “user friendliness” than, for instance, the choice of database deployment. For our work with setting user functionality for the PLT tool we included user interface wireframes for this tool, as a “picture” that expresses a thousand words in conveying the final overall functionality we want to obtain.

Results

Overview of the PLT tool

The Protocol Lifecycle Tracking (PLT) tool is envisioned to be a standalone application that can be adopted by researchers to assist in the evolution of a protocol. The PLT will provide a view of data from disparate sources and will function as a dashboard to access real-time data on demand for those with the appropriate access privileges. By using PLT, the following innovative advantages could be realized:

• Ability to manage the process flow to achieve compliance with associated timelines

• Documentation of the lifecycle of a protocol over its course.

• Ability to query status of protocol in real time.

• Visualization of the clinical trial process map for a specific site.

• Identify bottlenecks and/or redundant steps in the process.

• Allow for a comparison of the clinical trial process between sites and sponsors.

• Transparency of the clinical trial process between sites and sponsors.

• Enable access to metrics to evaluate performance.

• Enable automatic notifications and alerts to communicate completion status of essential milestones in the clinical trials process.

The foundation of the PLT tool is a library populated with generic templates of work flow Activities and associated Milestones (see Table 1). For example, the activity “IRB Approval” may have as associated milestones “Protocol Submitted,” “Protocol Reviewed,” “Protocol Conditionally Accepted,” and “Protocol Approved.” Each template can have expected normal time intervals for reaching these milestones assigned so that the progress of a trial’s activities can be flagged as proceeding normally or as being delayed. Activities and milestones can occur iteratively (as iterative IRB submissions with modifications), and they can occur concurrently with other activities or be dependent upon the successful completion of another activity.

Table 1.

PLT tool terminology.

Workflow Template	A Workflow Template is a user defined plan with one or more activities that serve as the basis for creating a Study Workflow. Templates serve as the starting point for creating a study-specific workflow which is applied to an actual clinical trial. Multiple templates can be created to account for variances between different types of trials.
Activity	An activity is a logical grouping of milestones that define a measurable amount of work or specific function. For PLT purposes, an activity can contain any number of milestones, including no milestones. In cases where an activity contains no milestones, the activity is in effect a milestone, but for the sake of consistency will still be defined as an activity. Activities are the building blocks for a Workflow Template. Only activities can be added to a template.
Milestone	A milestone is an event that indicates the completion of a major deliverable. Milestones are measurable and serve as progress markers, but by definition, are independent of time (meaning they have no duration), therefore no work or consumption of resources is associated with them. Milestones are sub-events within an activity and must be associated with an activity.
Dependency	A dependency is a relationship between activities or milestones. Dependencies include activities/milestones that cannot be started until a previous activity/milestone has completed and/or a pre-defined amount of time has elapsed since the completion of an activity/milestone.
Workflow Template Library	The Workflow Template Library is the collection of all of the defined Workflow Templates as well as the defined Activities that can be associated with a Workflow Template.
Study Workflow	A study workflow is a template that has been applied to a specific actual study. Once a template has been applied to a study, the Study Workflow becomes an independent entity distinct from the original template. The Study Workflow can be modified to suit the particular study to which is was assigned; however, these changes will not reflect back on the original Workflow Template.

These generic templates can be created with PLT for typical studies of different types (e.g., interventional cooperative group drug study) and for different perspectives (coordinating center vs. participating site). These templates can then be modified as needed for application to managing the process flow and tracking the progress of a specific study.

PLT tool Use Cases

A total of 63 use cases were defined and documented for the PLT tool and are publicly available.6 The actors and use case names are summarized in Table 2.

Table 2.

Summary of PLT tool actors and use cases.

Actors:

system administrator

coordinating center administrator

participating site administrator

clinical trials manager

coordinator

study team (e.g., data manager, protocol nurse)

Principal Investigator

Use Cases:

Manage Workflow Library

Manage Activities

Add New Activity

Create a New Activity

Set Default Activity Attributes

Add/Modify Activity Milestone(s)

Set Default Milestone Attributes

Set Default Milestone Dependencies

Verify and Approve Activity

Retire Activity

Select Activity

Retire Activity

Import/Export Activity Libraries

Manage Workflow Templates

Add New Workflow Template

Create a New Workflow Template

Add/Remove Activities from Workflow Template

Add/Remove Milestones from Workflow Template

Add Dependencies to Workflow Template

Verify and Approve Workflow Template

Retire Workflow Template

Select Workflow Template

Retire Workflow Template

Import/Export Workflow Template

Manage Study Plan Library

Create Study Plan

Select Workflow Template

Apply Workflow Template to Study

Modify Study Plan

Set Triggered Alerts

Verify and Approve Study Plan

Modify Study Plan

Select Study Plan

Modify Study Plan

Modify Triggered Alerts

Verify and Approve Study Plan

Stop Study Plan

Select Study Plan

Stop Study Plan

Re-start Study Plan

Import/Export Study Plans

Manage Study Plan

Update Study Plan

Select Study Plan

Select Activity and Milestone

Update Milestone Progress

Save Study Plan

View Study Plan

Select Study Plan

View Study Plan

Subscribe to Triggered Alerts

Select Study Plan

Select Activity/Milestone

Subscribe to Activity/Milestone

View Dashboard

Manage Portfolio

View Metrics

View Reports

Administer System

Manage User Access

Manage Study Roles

Manage Email Templates

Discussion

The complexity of protocol activities and milestones – that they may occur iteratively, or that they may occur concurrently or be dependent on successful completion of another, or that their occurrence at all depends on the trial’s sponsor – is managed primarily in the use cases “set default milestone attributes” and “set default milestone dependencies” as well as in the tool’s overall ability to have different templates and study plans for different protocols (e.g., cooperative group drug studies vs. investigator initiated non-interventional trial). The need for this flexibility is apparent if one considers a typical protocol initiation work flow as summarized in Figure 1. This schematic focusing on study initiation shows the different paths and activities necessitated for pharmaceutical industry trials, and the iterative nature of some processes. It should be kept in mind that this work flow is from the perspective of a participating site – a coordinating site would have a different work flow for activating the same protocol.

Figure 1.

Typical work flow requiring PLT tool representation.

A very significant benefit of using this tool will be the ability to manage the process workflow so that the clinical research staff know what activities are required, and when they are to be performed. Furthermore, delays in the anticipated schedule can be detected quickly and interventions undertaken to prevent a trial initiation from becoming “stuck.”

As mentioned above, non-cancer clinical trial work flows were also considered. While work flow details may differ, no disease-specific PLT requirements were encountered.

As had been stated in the Methods section, use case analysis is focused on the “what” rather than the “how.” While user interface specification in a sense crosses this boundary, several wireframes were prepared for our study of PLT tool use cases to convey the overall “look and feel” being sought. A wireframe of a possible dashboard for a clinical trials manager, showing a summary of the status of all trial either “in the pipeline” or currently open is shown in Figure 2. Using colors such as green and red for the circles in the two columns after each milestone listing would immediately convey whether the milestone had exceeded its anticipated completion time or not.

Figure 2.

Dashboard wireframe for a trials manager showing the status of various protocols.

Conclusion

These use cases have been made available to the public as noted in the Reference section. They have also been presented to the caBIG^® CTMS work space community and discussed at its meetings. The next step will be for software developers to write code for an application that satisfies these use cases.