StudyCalendar_vision_and_scope.doc - Northwestern University

assistantashamedΔιαχείριση Δεδομένων

29 Νοε 2012 (πριν από 4 χρόνια και 9 μήνες)

236 εμφανίσεις

Copyright © 1999 by Karl E. Wiegers. Permission is gra
nted to use, modify, and distribute this document.


Vision and Scope Document

for the

caBIG CTMS Study Calendar Module

Version 1.0 approved

Prepared by Warren A. Kibbe

The Robert H. Lurie Comprehensive Cancer Center of

Northwestern University

May 26, 2006

Vision and Scope for <Project>


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

................................
................................
............

3

3.

Scope and Limitations
................................
................................
................................
...

4

3.1.

Scope of Initial Release

................................
................................
.........................

4

3.2.

Scope of Subsequent Releases

................................
................................
...............

4

3.3.

Limitations and Exclusions

................................
................................
...................

5

4.

Business Context

................................
................................
................................
...........

5

4.1.

Stakeholder Profiles

................................
................................
...............................

5

4.2.

Project Priorities

................................
................................
................................
....

6

4.3.

Operating Environment

................................
................................
.........................

6





Revision History



Name

Date

Reason For Changes

Version









Vision and Scope for <Project>


Page
1


1.

Business Requirements

1.1.

Background

The business driver behind the c
aBIG 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
.
Studies that are
in scope

for this project include therapeutic, observational, correlative,
a
ncillary, and biobanking studies.

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 screening and registra
tion 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 M
arket 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 p
erspective, 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 al
so extends into computational capabilities, platforms, and
operational environments for the clinical research enterprise at each Cancer Center. Some
similarities are also apparent


the Cancer Centers that participate in caBIG predominantly have
Oracle lic
enses in place, and can host software incorporating Oracle databases. Therefore, for
the Study Calendar Module our primary database target is Oracle, and we have a subgoal of
making the Module transparently portable to PostgreSQL. The technologies chosen f
or the
implementation of the Study Calendar should be database
-
agnostic, providing 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
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 web
-
based, w
ith FireFox the web client of choice.


Vision and Scope for <Project>


Page
2


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 on
-
boarding adopters. Engagemen
t 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
mo
dules, 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 Stud
y 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 STM,
and CTOM, with the intent that additional modules that can consume or provide data
in
compliance with these models can tightly integrate with the Study Calendar Module. caAERS,
the Lab Interfaces Module, Financial Billing, EDC (electronic or ‘remote’ data capture tools), and
other CTMS modules are targets for application integration.


U
ser 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

and
registration
,
participant event tracking

specified by the study, tracking
par
ticipant
schedule deviation
s,
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.


The study calendar module will provide
st
udy
-
, participant
-
, and event
-
centric reports
, and
provide APIs for extending these reporting capabilities. The study calendar module will provide
views of participants by study that are necessary for periodic reporting, and working in
conjunction with mod
ules 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 intero
perable
tools,
any

module connected to the Study Calendar should be capable of pulling events and
Vision and Scope for <Project>


Page
3


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 th
e 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 S
tudy
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 prospective view i
s 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 tem
plate view, discrete
dates for future events can be calculated. This component will calculate when each event
actually takes place, working within the business rules of the organizations involved (hospital,
pharmacy, clinical research office, etc.) and th
e 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.


The third component to the Pat
ient 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
identifie
r for these events that can be used by other modules and systems.


Each of these components will include report generation tools, with the prospective and
retrospective views providing reports that can be study
-
, participant
-

or event
-
centric These
rep
orts 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 Calen
dar 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
a
nd 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 Depend
encies

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
Vision and Scope for <Project>


Page
4


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 approa
ch 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 var
ious caCORE SDK components, while placing the fundamental model
-
driven 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 T
emplate 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/ fo
llow
-
up lifecycle will be defined in the Study Calendar Template for a
specific study. The Study Calendar will provide 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 f
or tracking and managing periodic
reports to sponsors or insurers, the creation of financial milestones, hold financial data, hold
clinical or laboratory summaries or results. 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 view of any of those items can be produced. Although
our vision is to make all aspects of the Study Calendar Module completely open and
interoperab
le, 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 softw
are 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 add
itional analysis and modeling.


<Describe the intended major features that will be included in the initial release of the product.
Consider the benefits the product is intended to bring to the various customer communities, and
generally describe the produ
ct features and quality characteristics that will enable it to provide
those benefits. Avoid the temptation to include every possible feature that any potential
customer category might conceivably want some day. Focus on those features and product
characte
ristics that will provide the most value, at the most acceptable development cost, to the
broadest community.>

3.2.

Scope of Subsequent Releases

<If a staged evolution of the product is envisioned over time, indicate which major features will
be deferred to lat
er releases.>

Vision and Scope for <Project>


Page
5


3.3.

Limitations and Exclusions

<Identify any product features or characteristics that a stakeholder might anticipate, but which
are not planned to be included in the new product.>

4.

Business Context

<This section summarizes some of the business iss
ues around the project, including profiles of
major customer categories, assumptions that went into the project concept, and the
management priorities for the project.>

4.1.

Stakeholder Profiles

Currently identified Stakeholders include:


potential study calend
ar module adopters

the Study Calendar SIG members

the CTMS Workspace members

Cancer Centers with clinical trials

Cancer
-
focused Cooperative Groups

the NCI

the BAH CTMS project managers and coordinators


<Stakeholders are individuals, groups, or organizatio
ns that are actively involved in a project,
are affected by its outcome, or can influence its outcome. The stakeholder profiles identify the
customers for this product and other stakeholders, and states their major interests in the
product. Characterize bu
siness
-
level customers, target market segments, and different user
classes, to reduce the likelihood of unexpected requirements surfacing later that cannot be
accommodated because of schedule or scope constraints. For each stakeholder category, the
profile

includes the major value or benefits they will receive from the product, their likely
attitudes toward the product, major features and characteristics of interest, and any known
constraints that must be accommodated. Examples of stakeholder value include:




improved productivity



reduced rework



cost savings



streamlined business processes



automation of previously manual tasks



ability to perform entirely new tasks or functions



conformance to current standards or regulations



improved usability or reduced frustr
ation level compared to current applications


Example:>



Stakeholder

Major
Value


Attitudes


Major Interests


Constraints

executives

increased
revenue

see product as
avenue to 25%
increase in market
share

richer feature set than
competitors; time to
mark
et

maximum
budget = $1.4M

editors

fewer errors
highly receptive, but
automatic error
correction; ease of use;
must run on low
-
end
Vision and Scope for <Project>


Page
6


in work

expect high usability

high reliability

workstations

legal aides

quick access
to data

resistant unless
product is key
stroke
-
compatible with
current system

ability to handle much
larger database than
current system; easy to
learn

no budget for
retraining


4.2.

Project Priorities

<Describe the priorities among the project’s requirements, schedule, and budget. The table
below m
ay be helpful in identifying the parameters around the project’s key drivers (top priority
objectives), constraints to work within, and dimensions that can be balanced against each other
to achieve the drivers within the known constraints. For more informa
tion, see chapter 2 of
Creating a Software Engineering Culture

by Karl E. Wiegers (Dorset House, 1996). Examples:>


Dimension

Driver

(state objective)

Constraint

(state limits)

Degree of Freedom

(state allowable range)

Schedule

release 1.0 to be
available

by 10/1,
release 1.1 by 12/1



Features



70
-
80% of high priority
features must be included in
release 1.0

Quality



90
-
95% of user acceptance
tests must pass for release
1.0, 95
-
98% for release 1.1

Staff


maximum team size is
6 developers + 4
testers


Cost



budget overrun up to 15%
acceptable without executive
review


4.3.

Operating Environment

<Describe the environment in which the system will be used and define the major availability,
rel
i
ability, performance, and integrity requirements. This informati
on will significantly influence
the definition of the system’s architecture. Consider questions such as:



Are the users widely distributed geographically or located close to each other? How many
time zones are they in?



When do the users in various locations

need to access the system?



Where is the data generated and used? How far apart are these locations? Does the data
from multiple locations need to be combined?



Are specific maximum response times known for accessing data that might be stored
r
e
motely?



Can
the users tolerate service interruptions or is continuous access to the system critical for
the o
p
eration of their business?



What access security controls and data protection requirements are needed?>