C3PR Use Cases 2.5.5

From CTMS_WIKI

C3PR Architecture Guide 2.5.5 > C3PR Initial Configuration Guide 2.5.5 > C3PR Test Plan 2.5.5 > C3PR End User Guide 2.5.5 > C3PR Use Cases 2.5.5

1 Introduction
2 Actors and Roles
3 Manage Subjects
4 Manage Study
5 Manage Registration
6 Reporting
- 6.1 Advanced Registration Search
- 6.2 Study Search and Export
7 Administration
8 Integration
- 8.1 Synchronize Registration of a Subject on a Study Arm with Study Calendar

Introduction

Background

The Cancer Center Participant Registry (C3PR) is a web-based application used for end-to-end registration of patients to clinical trials. This includes capturing the consent signed date, eligibility criteria, stratification, randomization, and screening. Clinical workflows are enabled by both subject- and study-centric views into the registration process. C3PR can be run in a standalone mode where study definitions, investigators, study personnel, and sites are entered into the system, or C3PR can be run in an integrated mode with the caBIG Clinical Trials Suite (CCTS). C3PR also enables multi-site clinical trials where registration information is entered locally at affiliate sites and the registration is completed by call-out to the coordinating site.

Throughout the development of C3PR, a number of elaborator and adopter sites are actively being engaged to help define requirements and test the application. Our primary elaborators include Duke, Wake Forest, Mayo, Westat, CALGB, CCR, and the Coalition of Cooperative Groups. Our primary adopters include Duke and Wake Forest with engagement of Georgetown and CCR.

C3PR release 1 was developed by Nortel Solutions and released in 2006. Release 2 was developed by Duke Cancer Center in collaboration with SemanticBits, LLC and was released in March, 2008. We are currently in the next phase of development with releases slated for the end of September, 2008 and March, 2009.

Document Conventions

The C3PR Release 2 project follows the iterative development of the Unified Framework Process. Thus, each document is a snapshot of a work-in-progress. The following conventions will be used throughout the document:

will indicate new items that need to be addressed immediately in the next iteration by the developers.
will indicate new items that need to be addressed in the next iteration by the elaborators.

End User	Analysis	Technical	Management
C3PR Main Project Page End User Guide 2.5.5 Installation Guide 2.5.5 Configuration Guide 2.5.5 Release Notes Tear Sheet	Use Cases 2.5.5 Requirements Specification 2.5.5 Activity Diagrams 2.5.5	Architecture Guide 2.5.5 Deployment Diagrams 2.5.5	Project Plan 2.5.5 Scrum Artifacts Adoption Plan 2.5.5 Communications Plan 2.5.5 Test Plan 2.5.5 User Acceptance Tests 2.5.5 Arc Requests

Actors and Roles

The likely users of C3PR are people with the job responsibilities listed below. The role(s) granted to each user in the application will depend on the specific responsibilities of the person's job and other institutional rules under which they execute their responsibilities.

Registrar
Study Coordinator
Site Coordinator
System Administrator

The following table contains the different kinds of user groups:

System Administrator	Is a "super-user" who manages the application Grants users to a role within the application
Site Coordinator	Manages studies across the site Approves and manages user registration process Grants users to a role within the application Creates new studies in the system
Study Coordinator	Enters Study definitions in the system Reviews completed Study definitions to determine if they are complete and correct
Registrar	Enrolls Participants to Studies for which approval has been granted

Manage Subjects

Create Subject

Use Case Model

Brief Description	Existence of the subjects within the C3PR system is required for several use cases. In this use case a subject is created in the C3PR system.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged into the system with a user account that has role authority to create a Subject. The Subject doesn't already exist.
Basic Flow of Events	The user selects Create Subject The user is presented with a screen where details about the Subject are entered. The user enters the Subject data elements in the fields. The user submits the data If a subject with duplicate information is found in the system an alternate flow is introduced. The system displays the result page confirming the successful creation of a Subject.
Post Conditions	Subject data is stored in the system. The user is presented with a conformation of Subject creation.
Alternate Flow	The system shows an error for Subjects with a duplicate identifier. The user cancels the creation of the subject. The user changes the identifier value for a given system and creates the subject. The system displays the result page confirming the successful creation of the subject.

Special Requirements

Data Item	Notes/Validation Rule
Subject Identfier	At least one is required. The system will allow for any number of these to be specified and will capture the type of the identifier, the issuer of the identifier, and its value. This ID is uniquie to the Subject independent of the Subject's participation in a clinical trial.
First Name	Required
Middle Name	Not Required
Maiden Name	Not Required
Last Name	Required
Date of Birth	mm/dd/yyyy, forced format, Required
Gender	Coded, Required (Valid values include "unknown" and "not reported")
Race	Coded, Required (Valid values include "unknown" and "not reported")
Ethnicity	Coded, Required (Valid values include "unknown" and "not reported")

Brief Description	This use-case deals with searching for a subject. Reasons for searching for a subject include: Looking for duplicate subjects Begin subject registration in create registration workflow View registration details Update subject information Update registration
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to search for a subject.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a subject. The user selects the search basis on which he/she wants to perform the search. The user enters the search criteria for the subject and submits the information to the system. The system displays search results for subjects depending on the search criteria. If no result is displayed use the alternate flow.
Post Conditions	The resulting subject is in a state that the user can use to perform registration in create registration flow or simply to view subject details or to update subject details.
Alternate Flow	#The use changes the search criteria. The user submits the search critera.

Brief Description	This use case allows the user to view Subject's record.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The subject already exists.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a subject. The user enters the search criteria for the subject and submits the information to the system. The system displays 0, 1 or multiple subjects depending on the search criteria. The user selects a subject. The user views the subject details
Post Conditions	The subject details are displayed. The user can transition to Edit Use Case.

Brief Description	This use case allows the user to update Subject's record.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The subject record already exists.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a subject. The user enters the search criteria for the subject and submits the information to the system. The system displays 0, 1 or multiple subjects depending on the search criteria. The user selects a subject. The user views the subject details. The user selects the edit option for the displayed subject details. The user updates the subject detais.
Post Conditions	The subject record is updated.
Special Requirements	None.

Brief Description	Study Management is not the primary function of C3PR. However, Study Management is critical for the independent functioning of C3PR because registration is driven by the structure of the study. Therefore, it is included as a primary use case.
Primary Actor(s)	TBD
Secondary Actor(s)	TBD
Preconditions	TBD
Basic Flow of Events	TBD
Post Conditions	TBD
Alternate Flow	TBD

Brief Description	This use-case deals with the manual creation of a study by entering each data element of the study.
Primary Actor(s)	Site Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to create a study. The study has not already been entered.
Basic Flow of Events	The user indicates to the system that he/she wants to create a new study definition. The system displays the screen that gives the user the option of entering the study information manually. The user enters the study data elements in the fields. The user indicates to the system that the required study information has been entered for creation of a new study through a confirmation window with all of the study data items.
Extension	If this is a multi-site study that is shared across more than one organization, the user indicates to the system that the information must be broadcast to all participating organization sites.
Post Conditions	The study is created in the system. The study is created and defined as being in either "Pending" or "Active" status.
Alternate Flow	If a duplicate study is found then the user has to fix the details before it can be saved in C3PR.
Special Requirements	None.

Brief Description	This use-case deals with viewing a study.
Primary Actor(s)	Study Coordinator, Site Coordinator and Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has a role authority to view a study definition.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a given study definition. The user enters the search criteria for the study and submits the information to the system. The system displays 0, 1 or multiple study definitions depending on the search criteria. The user selects a study. All data items from the study are displayed
Post Conditions	The user can transition either to edit the use case or export the study use case.
====Special Requirements	None

Brief Description	This use-case deals with updating a study entry through the user interface. Note that this is different from a study amendment, which is a metadata item about an official change to a study.
Primary Actor(s)	Study Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to update a study definition.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a given study definition. The user enters the search criteria for the study and submits the information to the system. The system displays 0, 1 or multiple study definitions depending on the search criteria. The user selects a study and views that study. The user updates the necessary fields. The user saves the updated study information to the system.
Post Conditions	If the user is logged in to the system with a user account that has role authority to update a study, the study stands updated.
Special Requirements	The "Blinded" and "Multi-Institutional" data fields cannot be updated.

Brief Description	A study, depending on whether it is multi-site study or not can have multiple sites associated with it. Each site can have one or more personnel (Research Staff) involved in conducting the study. This use case deals with associating such staff with a Study. Site Coordinator, during the creation of a study definition, will be able to add one or many of the study personnel for the study.
Primary Actor(s)	Site Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with an administrative account that has role authority to add study personnel to the study organization. The organization already exists. The study exists. The intended research staff member already exists at that organization and has an "Active" status for that organization.
Basic Flow of Events	The user locates the study of interest The user indicates that he/she wants to associate study personnel. The user selects the desired organization for which the association should take place. The user chooses from the list of research staff existing at this organization to be assigned as study personnel The user chooses other relevant info for the association The user may select more research staff repeating the steps 1-4
Post Conditions	None.
Special Requirements	None.

Brief Description	A study can have multiple notifications associated with it. Every notification has a Threshold value associated with it. A notification email is sent when the number of registered participants reach the threshold value. These notifications can be either Email based or Role based. Email based notifications take an email address as input and Role based notificatinos send emails to all the email addresses in that role for that study.
Primary Actor(s)	Site Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with an administrative account that has role authority to add study personnel to the study organization. The study already exists. The intended roles and e-mail addresses for those roles that already exist in the C3PR system.
Basic Flow of Events	The user locates the study of interest The user indicates that he/she wants to add notifications. The user clicks on Add Notifications. The user enters a threshold value for which he wants the notification to be sent. The user enters an email address by clicking the Add email or selects a role by clicking on AddRole. The user may repeat the steps 1-5 as many times as desired.
Post Conditions	The notifications are set up such that when the registered participants reach the threshold value the corresponding email addresses/roles are notified.
Special Requirements	None.

Brief Description	Studies can have one or more stratification factors. Each stratification factor consists of a question and two or more discreet answers. The answers for a particular Subject on a Study determine the stratum group for the Study Subject. The stratum group can be used to help determine the arm during randomization.
Primary Actor(s)	Study Coordinator: defines the stratification when defining the study.
Secondary Actor(s)	Admin
Preconditions	The user is in the study creation or update workflow
Basic Flow of Events: Study Definition	The user enters the stratification portion of the study definition workflow The user adds zero or more stratification factors The user defines the question text for each stratification factor The user defines one or more discreet answers for each stratification factor The system saves the stratification factors
Basic Flow of Events: Subject Registration	The user enters the registration workflow The user navigates to the stratification tab The user answers each stratification factor question via drop-down menus The stratum group is displayed when then final stratification factor is answered The system saves the stratum group
Post Conditions	The system is ready to create a stratum group now.
Special Requirements	None.

Brief Description	Studies can have one or more Eligibility Criterion. These are further classified as Inclusion and Exclusion Eligibility criteria. The user can add new eligibility criteria to any treatment epoch. This use case helps add new eligibility criteria in 3 different ways depending on the business requirement.
Primary Actor(s)	Study Coordinator and Site Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is in the study creation or update workflow
Basic Flow of Events: Create Study	The user enters the eligibility portion of the study definition workflow. The user identifies the treatment epoch for which eligibility criteria needs be added. The user adds one or more inclusion or/and exclusion criterion. The user updates the study to save the newly added eligibility questions.
Alternate Flow (Load caDSR):	The user enters the eligibility portion of the study definition workflow. The user selects the treatment epoch for which eligibility criteria needs be added from a dropdown. The user adds clicks on the browse button and selects the file to be uploaded. The user clicks the upload button. The user can now add to or modify the uploaded contents.
Basic Flow of Events: Edit Study	If the desired study is saved in a pending status, the user enters the search criteria and searches for the desired study. The user selects the desired study and enters the edit workflow. The user enters the eligibility portion of the study. The user identifies the treatment epoch for which eligibility criteria needs to be added. The user adds one or more inclusion/exclusion eligibility criterion. The user updates the study to saves the newly added eligibility questions.
Basic Flow of Events: Amend Study	If the desired study is saved in an active status, the user enters the search criteria and searches for the desired study. The user selects the desired study and enters the amend study workflow. The user indicates that treatment epoch and eligibility change as a result of the amendment. The user enters the eligibility portion of the study. The user identifies the treatment epoch for which eligibility criteria needs to be added. The user adds one or more inclusion/exclusion eligibility criterion. The user updates the study to saves the newly added eligibility questions.
Post Conditions	New eligibility criteria is added to the study.
Special Requirements	None.

Brief Description	Studies can have one or more diseases associated with them. These diseases are used during Registration to allow the user to select a disease for a Study Subject. The user will also be able to select a primary disease site for the Study Subject. There are a number of different disease and disease site nomenclatures used in the community. C3PR will initally provide the CTEP diseases and disease sites.
Primary Actor(s)	Study Coordinator: defines the disease sites when defining the study Registrar: registers a subject to a study and, in doing so, defines the disease and disease site for the subject.
Secondary Actor(s)	None
Preconditions	None
Basic Flow of Events	The user enters the disease portion of the study definition workflow. The user adds one or more diseases.
Basic Flow of Events: Subject Registration	The user enters the registration workflow. The user navigates to the disease tab. The user selects a disease or enters a free-text disease. The user selects a disease site or enters a free-text disease site.
Post Conditions	A new disease and disease site are associated with the study.
Alternate Flow	None
Special Requirements	None

Brief Description	A new study entered into c3pr using the User Interface can be saved in a pending status. All the studies need at least one study site and one enrolling epoch and other basic data to be considered as data entry complete (which is system derived). The study has to go through a curation phase or a quality analysis check before the study coordinator or site coordinator reviews and can set the study status to open. This use case deals with this scenario.
Primary Actor(s)	Study Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to update study status from Pending to Open. The study is in a Pending status.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a given study definition. The user enters the search criteria for the study and submits the information to the system. The system displays 0, 1 or multiple study definitions depending on the search criteria. The user selects a study and views its summary. The user updates the study definition or any part of the study in the edit flow if required. The user updates the study status from Pending to Open.
Post Conditions	If the user is logged in to the system with a user account that has role authority to update study status, the study status is updated from Pending to Open.
Special Requirements	The system requires at least one study site. The system requires at least one enrolling epoch.

Brief Description	A study in an open status can be modified through an amendment. Once an amendment is anticipated or initiated, the user captures the study amendment information. However, at this stage the user may not have sufficient information to completely capture all the required information or the amendment may not have IRB approval yet. At this stage the system automatically puts the study in an Amendment Pending status. The study has to go through a quality analysis check before the study coordinator or site coordinator reviews and can update the study status from Amendment Pending to Open. This use case deals with this scenario.
Primary Actor(s)	Study Coordinator, Site coordinator or any other user of C3PR with role authority to update the status of a study to Open.
Secondary Actor(s)	None.
Preconditions	The user is logged in to the system with a user account that has role authority to update study status from Amendment Pending to Open. The study is in an Amendment Pending status.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a given study definition. The user enters the search criteria for the study and submits the information to the system. The system displays 0, 1 or multiple study definitions depending on the search criteria. The user selects a study and views its summary. The user goes through the amendment workflow and updates any information if required. The user updates the study status from Amending Pending to Active
Post Conditions	If the user is logged in to the system with a user account that has role authority to update study status, the study status is updated to Open.
Extension	If this is a multi-site study that is shared across more than one organization, the user indicates to the system that the modified information must be broadcast to all participating organization sites.
Special Requirements	None

Brief Description	This use-case deals with amending a current study definition.
Primary Actor(s)	Study Coordinator
Secondary Actor(s)	None.
Preconditions	The user is logged into the system with a user account that has role authority to amend a study definition. The study is in an active status.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a given study definition. The user enters the search criteria for the study and submits the information to the system. The system displays 0, 1 or multiple study definitions depending on the search criteria. The user selects the study definition for which he/she wants to amend. The user indicates to the system that he/she wants to make an amendment. The user enters the amendment data items
Post Conditions	The study definition has been amended.
Alternate Flow	None.
Special Requirements	None.

Brief Description	The study protocol version can be updated by amending a study with an open status. Once an update to the study site protocol version is anticipated or initiated, the user captures the information needed to update the protocol version. However, at this stage the user may not have completely captured all the required information or the update to the protocol version may not have IRB approval yet. At this stage the system automatically puts the update to the study in an Amendment Pending status. The update to the protocol version has to go through a quality analysis check before the study coordinator or site coordinator can update the study protocol version. This use case deals with this scenario.
Primary Actor(s)	Study Coordinator, Site coordinator or any other user of C3PR with role authority to update the status of a study.
Secondary Actor(s)	None.
Preconditions	The user is logged in to the system with a user account that has role authority to update study status from Amendment Pending to Open.
Basic Flow of Events	The user indicates to the system that he/she wants to search for a given study definition. The user enters the search criteria for the study and submits the information to the system. The system displays 0, 1 or multiple study definitions depending on the search criteria. The user selects a study and views its summary. The user goes through the amendment workflow and updates information for the protocol version update. After a quality analysis check of the protocol version update has been performed and IRB approval has been received, the user updates the study status from Amending Pending to Open.
Post Conditions	If the user is logged in to the system with a user account that has role authority to update study status, the study protocol version is updated.
Extension	If this is a multi-site study that is shared across more than one organization, the user indicates to the system that the modified information must be broadcast to all participating organization sites.

Brief Description	This use case will allow the user to register a subject not currently in the C3PR system to a study. The user will be required to enter subject information before completing the registration.
Primary Actor(s)	Registrar or any other designated user of C3PR with role authority to register a Subject.
Secondary Actor(s)	None.
Preconditions	The Study already exists. Any hard accrual limits are not exceeded. The Study is in Active status. The study has an enrolling epoch. The subject does not already exist in the system. The subject meets the eligibility criteria for the enrolling epoch.
Basic Flow of Events	The user enters create registration workflow The user creates a new subject. The user searches and selects the desired study The user selects a study site The user selects an enrolling epoch from the selected study. The system alerts the user of any soft accrual limits. The system alerts the user if the subject is already registered to the same study. The user fills out the enrollment details completely. If the study involves Randomization, the user indicates to the system that he/she wants to randomize
Post Conditions	If the enrolling epoch involves randomization, an arm is successfully obtained. If the user was logged in to the system with a role authority to register a subject, the subject is registered to the study.
Alternate Flow	None.
Special Requirements	None.

Brief Description	The user must first create a registration in the appropriate study site before they can enroll a subject. This use case will explain how the user can create a registration in a study site in a multi-site study. In order to register a subject to a study site of a multi-site study the study must already exist the system and have an Open status. Once the registration has been created go to the Enroll Subject to Study Site use case and follow the steps to complete the registration of a subject.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to register a Subject. The Study already exists. Any hard accrual limits are not exceeded. The Study is in Active status. The study has an enrolling epoch. The subject meets the eligibility criteria for the enrolling epoch.
Basic Flow of Events	The user enters create registration workflow The user searches and selects the desired multi-site study The user selects the desired study site The user selects an enrolling epoch from the selected study. The system alerts the user of any soft accrual limits. The system alerts the user if the subject is already registered to the same study. The user fills out the enrollment details completely. The system sends the registration notification fo the ESB. The ESB sends the registration notification to the coordinating center for approval. The system gets back either an approval or a disapproved message back from the coordinating center.
Post Conditions	If the subject meets eligibility criteria, he/she is successfully registered. If the enrolling epoch involves randomization, an arm is obtained.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use case will explain how the user can enroll a subject to a study site in a multi-site study after they have created the registration. The user must first create a registration in the appropriate study site before they can enroll a subject. Once the steps in the Register Subject to Multi-site Study use case have been completed the user can follow the steps in this use case to enroll a subject in the registration of a study site.
Primary Actor(s)	Registrar or any other designated user of C3PR with role authority to register a Subject.
Secondary Actor(s)	None
Preconditions	Registration is pending Randomization of study subjects is complete
Basic Flow of Events	The user searches and selects the desired study The user enters create registration workflow and broadcasts the registration The user changes the status of an existing subject. The user selects an enrolling epoch from the selected study. The system alerts the user of any soft accrual limits. The system alerts the user if the subject is already registered to the same study. The user fills out the enrollment details completely.
Post Conditions	If the user was logged in to the system with a role authority to register a subject, the subject is registered to the study.
Alternate Flow	None.
Special Requirements	None.

Brief Description	Before you can transfer subjects from one epoch to another you must first transfer the epoch to the appropriate study site in the multi-site study. In this use case an epoch is changed in the system to be stored in a study site.
Primary Actor(s)	Study Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to register a Subject.
Basic Flow of Events	The user searches for the appropriate study The user selects the study to edit it The user selects or adds the appropriate epoch The user broadcasts the epoch to study sites
Post Conditions	The epoch is now stored in the appropriate study site of the multi-site study.
Alternate Flow	None.
Special Requirements	None.

C3PR Use Cases 2.5.5

From CTMS_WIKI

Contents

Introduction

Background

Document Conventions

Related Documentation

Actors and Roles

Manage Subjects

Create Subject

Search for a Subject

View a Subject

Update Subject Details

Manage Study

High Level Study Diagram

Data Capture Diagram

Create Study Definition Manually

Search for Studies

View Study

Update Study

Associate Study Personnel Study

Add Notifications to Study

Add Stratification

Disable a Stratum Group

Add Eligibility Criteria

Add Diseases

Change Status from Pending to Open

Change Status from Amendment Pending to Open

Update Study Definition

Update Study Protocol Version

Manage Registration

Register a New Subject

Register Subject to Multi-site Study

Enroll Subject to a Study Site

Transfer Epoch to Study Site of Multi-site Study

Assign Subject to New Epoch in Study Site

Register Existing Subject to a Study

Assign Kit Number for Blinded Study

Save a Registration in Incomplete Status

Register Subject to Reservation Study

Search for Registrations

View Subject Registration History

Update Eligibility Status for Registration

Randomize Subject

Take Subject Off Study

Unblind Registered Subject

Reporting

Advanced Registration Search

Study Search and Export

Administration

Create Investigator

Add Investigator Group

Add Investigator To A Group

Create Research Staff

Create Organization

Associate Investigator to Study Organization

Associate Investigator Group to Study Organization

Search for a Study Personnel

View and Update Research Staff Details

Search for an Investigator

List Investigators In A Group

View or Update Investigator Details

Disassociate Study Person from Study Site

Change the Study Site Investigator status

Export Study Definition to a File

Export Registration Definition to a File

Import Study Definition from a File

Get Study Definition via Study Message from External Source

Integration

Synchronize Registration of a Subject on a Study Arm with Study Calendar

Views

Personal tools

KC Contents

Tools/Products

KC Projects

Other Resources

External Links

Search

Toolbox

Brief Description	Subjects can be assigned to an epoch in a study site after the epoch has been transferred to the study site of a multi-site study. You will need to change the registration status of the subject and broadcast the information to the study sites associated with the multi-site study. In this use case a subject is assigned to an epoch in a study site of a multi-site study.
Primary Actor(s)	Study Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to register a Subject. If randomization is selected for the study then randomization of the subjects must be complete
Basic Flow of Events	The user searches for the appropriate study The user selects the study to edit it The user selects or adds the appropriate subject The user broadcasts to study sites
Post Conditions	The subject is now assigned to the appropriate epoch of the multi-site study.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use case allows the user to select a study and select a subject and without entering other details, save the information in an incomplete status. Users can then search for the registration and complete the information and the registration will either go on pending status if it requires some approval, if it's a multi site study or it can be accepted as a complete registration.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to register a Subject. The Study already exists. Any hard accrual limits are not exceeded The Study has an Active status. The Subject is not already registered to the same Study.
Basic Flow of Events	The user enters create registration workflow The user searches and selects the desires subject. The user searches and selects the desired study The user selects a study site The user selects an epoch from the selected study. The system alerts the user of any soft accrual limits. The system alerts the user if the subject is already registered to the same study. The user fills out the enrollment details incompletely i.e. either the treating physician is not entered or eligibility is not met or Informed Consent Version or Date is not valid.
Post Conditions	The registration is saved in an incomplete status if no hard accrual limits are exceeded or the subject is not already registered to the same study site.
Alternate Flow	None.
Special Requirements	None.

Brief Description	In some Phase I studies, there are very small number of accrual slots. It is important that someone can be registered to the study, get worked up, and then potentially be removed from the study. This type of "reservation" allows the next candidate to take the originally registered slot. This differs from most studies, where the de-registered slot is "lost" - the next subject is registered to the next slot.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with a user account that has role authority to reserve a spot on the study. The Study already exists. Any hard accrual limits are not exceeded The Study is in Active status. The study has a reserving or enrolling epoch. The subject already exists.
Basic Flow of Events	The user enters create registration workflow The user searches and selects the desired subject. The user searches and selects the desired study. The user selects a study site. The user selects a reserving or an enrolling epoch from the selected study. The system alerts the user of any soft accrual limits. The system alerts the user if the subject is already registered to the same study. The user fills out the enrollment details.
Post Conditions	The subject is reserved a spot on the study.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use-case deals with searching for registrations. Reasons for searching for registrations include: Looking for duplicate registrations View registration history Check for eligibility requirements Check registration status Modify a registration To assign a subject to a randomized arm
Primary Actor(s)	Study Coordinator, Site Coordinator and Registrar
Secondary Actor(s)	Registrar
Preconditions	The user is logged in to the system with a user account that has role authority to search for a registration.
Basic Flow of Events	The user indicates to the system that he/she wants to search for registrations. The system displays a 2-step search process. The user first searches for a subject, study or a registration identifier based on subject search criteria, study search criteria or the registration identifier value respectively. The user then searches for the registrations based on the selected subject, study or registration identifier The system displays 0, 1 or multiple registrations depending on the search criteria.
Post Conditions	The resulting registration list is in a state that the user can transition to any of the manage registration use cases like completing, updating eligibility, assigning to a randomized arm, updating registration status etc. This means sufficient detail is presented to the user in order to determine which registration to transition to.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use case allows the user to view registration details of a subject.
Primary Actor(s)	Registrar, Site Coordinator, CRA or any other designated user of C3PR with role authority to view a registration.
Secondary Actor(s)	Registrar
Preconditions	The subject is already registered to a study at a particular healthcare site. The user is logged into the system with a user account that has role authority to view registration details.
Basic Flow of Events	The user searches for a given subject. The user selects desired subject to view the subject details. The user indicates that he/she wants to view the desired registration from a list of registrations the subject is on. The user can choose to view registration details, eligibility status, registration status, stratification factors, randomization arm, and registration identifiers.
Post Conditions	#The registration details have been viewed by the user.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use case allows the user to assign a subject to an arm.
Primary Actor(s)	Registrar
Secondary Actor(s)	Admin
Preconditions	The subject is already registered to a study at a particular healthcare site. The user is logged into the system with a user account that has role authority to assign a subject to a randomized arm on a given study.
Basic Flow of Events	The user searches for a given subject. The user selects desired subject to view the subject details. The user indicates that he/she wants to view the desired registration details from a list of registrations the subject is on. The user indicates that he/she wants to view the randomization information of the subject on the given study by selecting the randomization tab. The user selects the desired arm to which the subject is to be assigned indicates to the system that he/she wants to save the arm.
Post Conditions	If the user has the role authority to assign the subject to a randomized arm on the given study, the subject is assigned to a randomized arm.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use case involves the unblinding of a subject registered to a blinded study. The purpose of unblinding is to make the previously unknown treatment known. This use case is invoked for a variety of reasons, including the subject having an adverse event, the subject requesting to know the treatment, and someone other than the subject taking the subject's medication. Note that this use case does not result in any functionality in C3PR because there is no need to track unblinded information in the registration tool - it is tracked in the CDMS. However, it is included for completeness.
Primary Actor(s)	Unblinding Requester (e.g. treating physician), Kit Manager (e.g. coordinating site, drug provider)
Secondary Actor(s)	Study Coordinator
Preconditions	The subject is registered to a treatment epoch of a (double) blinded study.
Basic Flow of Events	The Unblinding Requestor requests that a subject is unblinded by providing a kit number and reason to the Kit Manager The Kit Manager provides the treatment information to the Unblinding Requestor The Unblinding Requestor fills out the appropriate unblinding CFRs and logs them in the CDMS
Post Conditions	The study subject is unblinded
Alternate Flow	# The Study Coordinator intervenes in the flow before the Kit Manager provides the treatment information to determine which information is released to which individuals
Special Requirements	Note: this use case does not result in any functionality within C3PR.

Brief Description	This use case allows the user to enter information in 4 different kinds of criteria and run a registrations search. The search results table also allows the user to download the results in .xls format.
Primary Actor(s)	Site Coordinator, Study Coordinator and Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with an account that has permission to search registrations.
Basic Flow of Events	The user enters the desired search criteria. The four criteria are: Study, Site, Registration and Subject. The user retrieves the corresponding registrations. The user downloads the table in the .xls format.
Post Conditions	The search results are displayed in a table on the same page. This table provides a export as excel button which lets the user download the table contents in excel format.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use case allows the user to search for studies and export the search result as an excel file.
Primary Actor(s)	Site Coordinator, Study Coordinator and Registrar
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with appropriate privileges One or more studies must exist in the C3PR database
Basic Flow of Events	The user enters the desired search criteria. The user can search on 3 criteria's: Study # # Identifiers, Study Short Title and Study Status The system retrieves the corresponding studies The user downloads the table in the .xls format.
Post Conditions	The search results are displayed in a table on the same page. This table provides a export as excel button which lets the user download the table contents in excel format.
Alternate Flow	None.
Special Requirements	None.

Brief Description	This use-case deals with the manual addition of Investigators to a group at a healthcare site.
Primary Actor(s)	Site Coordinator
Secondary Actor(s)	Admin
Preconditions	The user is logged in to the system with an administrative account that has role authority to create an investigator group. The desired investigator(s) do not already belong to the group.
Basic Flow of Events	The user indicates to the system that he/she wants to perform an administrative task The user indicates to the system that he/she wants to add investigators to a group. The system displays the screen that gives the user option of selecting an organization and the desired investigator group. The user selects from the list of existing investigators at the organization, those that he/she intends to be add to the group. The user indicates to the system to save the new information.
Post Conditions	If the user is logged in to the system with a user account that has administrative privileges to add Investigators to a group, the Investigators would be added to the group.
Alternate Flow	None.
Special Requirements	None.