Vision and Scope Document

for the

caBIG CTMS Study Calendar Module

Version 1.03

Prepared by Warren A. Kibbe

The Robert H. Lurie Comprehensive Cancer Center of Northwestern University

June 26, 2006

Vision and Scope for <Project>the caBIG CTMS Study Calendar Module

Page ii

Table of Contents
Table of Contents ................................................................................................................ ii Revision History ................................................................................................................. ii 1. Business Requirements ................................................................................................. 1 1.1. Background ............................................................................................................ 1 1.2. Business Opportunity ............................................................................................ 1 1.3. Business Objectives and Success Criteria ............................................................. 1 1.4. Customer or Market Needs .................................................................................... 1 1.5. Business Risks ....................................................................................................... 2 2. Vision of the Solution ................................................................................................... 2 2.1. Vision Statement.................................................................................................... 2 2.2. Major Features ....................................................................................................... 3 2.3. Assumptions and Dependencies ............................................................................ 4 3. Scope and Limitations................................................................................................... 4 3.1. Scope of Initial Release ......................................................................................... 5 3.2. Scope of Subsequent Releases ............................................................................... 5 3.3. Limitations and Exclusions .................................................... ! 4. Business Context............................................................................ ! 4.1. Stakeholder Profiles ................................................................ ! 4.2. Project Priorities ..................................................................... ! 4.3. Operating Environment .......................................................... !

Revision History
Name Warren Kibbe Warren Kibbe Date June 5, 2006 June 5, 2006 Reason For Changes Revisions to 1.0 based on Study Calendar Kickoff call Revisions from Study Calendar SIG call. In particular, making PostgreSQL the primary target and calling out the extension of the study calendar to additional relational databases was an outcome of the June 5 call. We should make a glossary of terms, with many of the bolded or italicized words such as offtracking defined in that glossary. Scope corrections and limitations based on SIG and requirements calls Version 1.01 1.02

Warren Kibbe

June 23, 2006

1.03

Vision and Scope for <Project>the caBIG CTMS Study Calendar Module Page 1

1. Business Requirements
1.1. Background
The business driver behind the caBIG CTMS Study Calendar Module is the creation of an open source, standards-compliant software application that can be used by organizations that manage patients on cancer clinical trials. The Study Calendar module will support the application of a study template to study participants and enable the prospective forecasting of visit information and provide a framework for reviewing historical study calendar events. Prospective studies that are linked to patient identifiers and data are in scope for this project include prevention, therapeutic, observational, correlative, ancillary, screening, diagnostic, and biobanking studies. These studies may or may not include consent. Studies that do not involve clinical data or studies that are purely laboratory-based are out of scope. Although the Study Calendar is not explicitly responsible for tracking protocol changes or amendments to the study, changes to the study can be consumed by the Study Calendar Module to reflect changes to the study calendar template and the application of those changes to a participant.

1.2. Business Opportunity

At this point in time, and open source, open standards-based study calendar does not exist.

1.3. Business Objectives and Success Criteria

Although the long term benefit to be derived from the Study Calendar are the standards-based interfaces and data definitions, the short term objectives and measurable success metrics are around having a Study Calendar application that enables the creation of a study calendar template for a study, the events around the screening and registration of a participant on a study, provides a study-specific forecast calendar at a patient level, provides a retrospective view of participant events, and provides study-, participant-, and event-based reports focused on the study calendar.

1.4. Customer or Market Needs

The immediate focus for the Study Calendar Module are NCI-designated Cancer Centers, followed by the Cooperative Groups, Cancer Center-affiliates, and finally other organizations that open NCI-sponsored clinical trials. From the Cancer Center perspective, the ability of the Cancer Center to acquire and host open source software is not correlated with the size, nature (matrix or standalone), maturity or clinical trial load of the institution. The heterogeneity of the Cancer Center environments also extends into computational capabilities, platforms, and operational environments for the clinical research enterprise at each Cancer Center. Some similarities are also apparent many of the Cancer Centers that participate in caBIG have at least one Oracle license in place, and can host software incorporating Oracle databases. However, in the Study Calendar SIG, an informal poll revealed that Ingres, Sybase, and SQLserver were the relational database platforms of choice at Mayo, Dartmouth and City off Hope. Therefore, the Study Calendar Module will be built against PostgreSQL and be crossdeployable on other relational databases, although the validation of additional database targets will be an adopter task. The technology (Hibernate) that provides the object/relational mapping for the Study Calendar Module provides this flexibility for little additional work. Likewise, to make the software application as easy to setup and maintain as possible, the application server technology will be as lightweight as possible and installable through a

Vision and Scope for <Project>the caBIG CTMS Study Calendar Module Page 2

standard install procedure. The adopter site will be able to install the database and application server on the same server, or distribute them for better performance. Client access will be webbased, and will support browsers that follow current web standards.

1.5. Business Risks

Clear definitions, buy-in from cancer centers and cooperative groups, harmonization with BRIDG, CTOM, CDISC. Rapid feedback from cancer centers. Delays in identifying and onboarding adopters. Engagement of caBIG stakeholders from the community is paramount, and the mechanisms for engagement need to be well defined and mutually acceptable.

2. Vision of the Solution

2.1. Vision Statement
The caBIG CTMS Study Calendar Module will support the application of a study template to study participants and enable the prospective forecasting of visit information and provide a framework for reviewing historical study calendar events. The caBIG CTMS Study Calendar will support studies that include therapeutic, observational, correlative, ancillary, and biobanking aspects. The standalone Study Calendar module will integrate with the components necessary to create study calendar templates (protocol authoring), be able to instantiate a template for study participant and represent study events for that participant. These study events will be uniquely identified at a study participant and event level, enabling the stable linking to external systems such as patient scheduling systems, laboratory interfaces, adverse event reporting modules, case report forms, and other event-based data that are specified by a study. The study calendar will serve as an event-centric hub for linking these data, but the study calendar module itself will not model or extend into these domains. The Study Calendar will provide APIs to data for data sharing and application interaction. The data model will be based on and harmonized with the caBIG BRIDG model, the CDISC SDTM/TDM, and CTOM, with the intent that additional modules that can consume or provide data in compliance with these models can effectively integrate with the Study Calendar Module. caAERS, the Lab Interfaces Module, Financial Billing, EDC (electronic or remote data capture tools), with open source CTMS systems including OpenClinica, and other CTMS modules all identified as potential targets for application integration. User Interfaces A minimal study calendar template creation interface will be included in the deliverables for the Study Calendar Module. The module will include stubs for the still to be developed standardized interfaces that will enable future integration with a complete protocol authoring tool and a study calendar template repository. The Study Calendar Module will include interfaces that support study participant screening events and registration events, participant event tracking specified by the study, tracking participant schedule deviations, off-tracking of the participant, track arm assignment, and support the entry of study events that are necessary for outcomes analysis but not found on case report forms, as necessary.

Vision and Scope for <Project>the caBIG CTMS Study Calendar Module Page 3

The Study Calendar Module will provide a small cohort of study-, participant-, and eventcentric reports chosen by joint prioritization with the Study Calendar SIG, and provide APIs for extending these reporting capabilities to meet additional use cases including ad hoc reporting needs. The Study Calendar Module will provide views of participants by study that are necessary for periodic reporting but unless explicitly given a high priority by the SIG will not include the actual reports. The Study Calendar Module will work in conjunction with modules such as caAERS will provide the necessary data for those reports. Again, the vision is that the Study Calendar Module is an event hub, not a data hub, although it will clearly represent and hold event information. In an idealized environment of interoperable tools, any module connected to the Study Calendar should be capable of pulling events and data through the study calendar representation from the full collection of integrated CTMS data and workflow tools.

2.2. Major Features

The Patient Study Calendar module will have three functional components that reflect the three aspects of the data model: a template view, a prospective view, and a retrospective view. Each of these components has a set of business rules associated with it. The template view of the Patient Study Calendar module is an electronic representation of the eligibility/treatment/monitoring/follow-up lifecycle for a specific study, as typically listed in the study parameters table of the study protocol. The template view in the standalone Study Calendar module will integrate with the components necessary to create study calendar templates (protocol authoring) using the BRIDG model and will contain the interface elements necessary to create a study specific template. The creation of an event and the specification of the items in a multi-level event container is the purview of the protocol authoring module. The representation of that specification can be held by either the protocol authoring or study calendar system. However, a basic interface allowing the creation of a multi-level event container will be part of the stand alone Study Calendar Event Module application. An example of such an event is a blood draw that is scheduled for day 15 of cycle 1 of the patient calendar, with the specification that the blood draw is for three purple-top EDTA tubes (3-10ml), one used for a CBC, one for archival to a biobank, and one for CA-125 (ovarian cancer). The prospective view is the result of applying the template view to a specific participant with a start date. The prospective view is an instantiation of the template for a study participant and by combining the start date of that participant with the days specified in the template view, discrete dates for future events can be calculated. This component will project the future occurrence of each study event for that participant, working within the business rules of the organizations involved (hospital, pharmacy, clinical research office, etc.) and the protocol. The prospective view is where the workflow and business rules for notification of pending patient visits, pending lab tests and accrual definitions are applied. These study events will be uniquely identified at a study participant and event level, enabling the stable linking to external systems such as patient scheduling systems, laboratory interfaces, adverse event reporting modules, case report forms, and other event-based data that are specified by a study. Likewise, the Study Calendar Module will provide those systems with methods to store stable identifiers for linking to associated data for an event in the Study Calendar. The third component to the Patient Study Calendar module is the retrospective view. Once the date of an event created by the prospective component has passed, details about that event must be entered to reconcile if it happened, when it happened, and provide a unique, stable identifier for these events that can be used by other modules and systems.

Vision and Scope for <Project>the caBIG CTMS Study Calendar Module Page 4

Each of these components will include a select set of reports as defined by the Study Calendar SIG and adopters, with the prospective and retrospective views accessible by APIs that can provide study-, participant- or event-centric slices of the study calendar. These reports and APIs will support the study calendar requirements of the various users of the Study Calendar Module, including physicians, nurses, pharmacists, clinical research coordinators, study financial coordinators, and participants. Functionally, the Study Calendar will include features to support patient screening and registration, adaptable schedule definitions and security model implemented using the CSM that is suitable for multi-site protocols, alerts for upcoming events and missed events, ability to track and report on dates of anticipated versus actual events, and complete reporting of patient accrual, missed events, and schedule deviations. The Patient Study Calendar will support the accrual definitions necessary for CCSG reporting.

2.3. Assumptions and Dependencies

A key outcome of the project will be the implementation of a BRIDG model-derived architecture that is harmonized with CTOM and CDISC, utilizing NCICB components such as caCORE SDK, CSM and caAdapter (HL7 SDK) to prepare for subsequent achievement of caBIG Gold-level compatibility, inclusion of the Study Calendar on caGrid, and use of the Study Calendar as a core component of the caBIG CTMS ecosystem alongside systems such as C3D, caAERS, and OpenClinica. The project team will pursue a phased approach to ensure well-coordinated development and completion of timely, quality deliverables. Project tasks include planning, stakeholder and caBIG CTMS Study Calendar SIG engagement, design, and implementation. These tasks will leverage and integrate with various caCORE SDK components, while placing the fundamental modeldriven development architecture in place to achieve gold compatibility and incorporation into caGrid at a later stage. Engagement of caBIG stakeholders from the community is paramount, and the mechanisms for engagement need to be well defined and mutually acceptable.

3. Scope and Limitations

The current funded cycle of the Study Calendar Module will result in an operational Study Calendar that provides interfaces for creating the Study Calendar Template for each study, and provides workflow management interfaces for the eligibility/ registration/ treatment/ monitoring/ follow-up lifecycle at the level of a participant. The specific events in the eligibility/ registration/ treatment/ monitoring/ follow-up lifecycle will be defined in the Study Calendar Template for a specific study. The Study Calendar will provide APIs, UI screens, and a small set of core reports of screening and registration information for participants on a study, study-specified events, and general workflow management tools for the patient relative to the study requirements for that protocol. The Study Calendar will not provide tools for tracking protocol creation, CPSRMC review, IRB review (neither initial or periodic), track adverse events, the reporting of adverse events, tools for tracking and managing periodic reports to sponsors or insurers, the creation of financial milestones, hold financial data, hold clinical or laboratory summaries or results. As stated in section 2.1: The study calendar will serve as an event-centric hub for linking these data, but the study calendar module itself will not model or extend into these domains. The Study Calendar will, however, be able to provide stable, unique identifiers to patient events that can be used by systems or modules that manage those domains so that a calendar-driven

Vision and Scope for <Project>the caBIG CTMS Study Calendar Module Page 5

view of any of those items can be produced. The Study Calendar Module will also provide methods to systems supporting these data for the storage of stable, unique identifiers enabling the linking of data from those systems to specific events in the Study Calendar Module. Although our vision is to make all aspects of the Study Calendar Module completely open and interoperable, we anticipate that the initial release will primarily offer data-level interoperability rather than complete access to all methods and interface elements in the study calendar application.

3.1. Scope of Initial Release

We will use an Agile approach to software design, where we will release many small iterations of production quality code so that we can get finished code into the hands of the adopters rapidly for their evaluation so we can rapidly identify areas that are stable as well as areas in need of additional analysis and modeling. The initial release will focus on the study calendar template, which is the study-centric view of the study calendar. We will include the UI elements for creating and editing the template elements, and reports for reviewing existing templates and viewing the elements present in a template. Additional details on the deliverables are available in the Project Management Plan.

3.2. Scope of Subsequent Releases

The Study Calendar six month timeline includes four releases, roughly every six weeks. Each release will include additional features and build on the previous release. Additional details on the deliverables are available in the Project Management Plan.