CCTS Application Roles - Draft
From CTMS_WIKI
Contents |
Introduction
Overview
In the first two releases (1.0 and 1.1) of the caBIG Clinical Trials Suite, roles and security were managed separately in each individual application. For Release 2.0 of the Suite, to improve coordination and consistency between applications, the Clinical Trials Management Systems Interoperability Working Group (CTMSi WG) would like to propose a set of roles that takes into account the range of common and distinct functions provided across the Suite and simplifies the management of role assignment for sites that adopt the Suite. Cancer centers and other organizations that manage clinical trials have different policies surrounding application and data access/security. The CTMSi WG recommends that the caBIG Clinical Trials Suite provide flexibility and convenience by defining roles based on common groupings of functions from an end-user’s perspective rather than from an application-oriented perspective. This document describes those roles and functions and identifies the assumptions upon which these recommendations are based.
Assumptions
The following statements are assumed to be true and describe the context in which the roles identified in this document were conceived:
- The framework of the caBIG Clinical Trials Suite aims to enable compliance with institutional policies and legal/regulatory requirements, rather than enforcing such. For example, the law may state that within a study the information must be handled in an ethical and responsible manner, but different institutions may implement that security in different ways. Some institutions require contracts with staff in which they agree to access data on a need-to-know basis and grant access to a wide range of data.
- In a hosted environment, if there is a multi-site study administered by a coordinating center, the participating sites are only allowed to read/update subject data for subjects at their site.
- Roles for a grid environment require significant discussion and are not within the scope of this set of proposed roles.
- Roles need to be defined at a granular, function-based level to allow sites that divide the tasks at a granular level to grant access appropriately. The roles proposed here are envisioned as out-of-the-box roles that could be implemented in CCTS 2.0, with the ability to assign these directly to users and the ability to define new roles as combinations of these to make role-to-user assignments easier for administrators to perform when one person performs many functions.
- Roles across all applications could be managed together.
- Roles and functions required for the new use cases for CCTS release 2.0 (e.g. protocol authoring, etc.) are TBD at this time and will be identified after the 2.0 interoperability scenarios have been selected for further development.
Clinical Trials Management Systems Interoperability Working Group
The Clinical Trials Management Systems Interoperability (CTMSi) Working Group members who contributed to this effort include:
- Vijaya Chadaram, Duke University
- Sharon Elcombe, Mayo Clinic
- Jomol Mathew, Dana Farber Cancer Center
Analysts
The analysts who facilitated the discussions, documented decisions, etc. on this effort include:
- Wendy Ver Hoef, ScenPro, Inc.
- Libby Prince, Sapient
- Smita Hastak, ScenPro, Inc.
Note: Libby Prince is a DSIC Analyst. She participated in this activity with the CTMSi Working Group and Analysts so that the group could ensure that DSIC point of view for roles was being addressed.
Proposed Roles
This section documents the roles proposed by the CTMSi Working Group for use and implementation in the CCTS applications for release 2.0.
Notes:
- The abbreviations CC and PS refer to the Coordinating Center and Participating Sites, common terms used in the CTMS Business Architecture Model (BAM) to distinguish between high level functions of the organizations involved in clinical research.
- The working group deferred to the CCTS architects the determination of how the suite would be installed in CC-hosted and 3rd party-hosted environments.
| App Role Name | Apps | Functions and Responsibilities | BAM Use Cases | Local Installations: (CC/PS) | Study-Specific | Comments |
|---|---|---|---|---|---|---|
| User Administrator | All | Creates and manages user accounts/application roles; defines Custom Combination Roles | - | CC & PS | no | - |
| Organization Info Manager | All | creates and updates org info and network info
NOTE: this might need to be broken into 2 roles, one for research network rosters and one for local organizational relationships - might need some feedback from other community members on this | ECR > Manage Organization > Manage Organization Information | CC & PS | no | - |
| Research Staff Info Manager | All | creates and updates person info including contact info, degrees/certifications, rosters they’re associated with | ECR > Manage Person | CC & PS | no | - |
| Study Manager (for core study data) | All | Create and manage studies; creates the core study info (e.g. PI, title, description, phase, epochs/arms & basic study design, etc.)
NOTE: some sites may want to combine the supplemental study info roles into this role (Coordinating Center AE Rule Manager, Participating Site AE Rule Manager, Coordinating Center AE Report Manager, Participating Site AE Report Manager, caAERS Supplemental Study Info Creator, C3PR Supplemental Study Info Creator, Coordinating Center Study Calendar Template Manager, Coordinating Center Study Calendar Template QA/QC) - TBD | - | CC | no | - |
| Study Importer | All | identifies studies defined by Coordinating Center and imports as a consumer that data defined elsewhere | - | PS | no | push or pull? Push works if you know who is participating but pull is better if you don't know, e.g. ECOG has a study that not all sites will want to participate in |
| Coordinating Center Study Team Administrator | All | connects study level people to the study and internal staff to the study | - | CC | no/yes | - |
| Coordinating Center Study Site Participation Administrator | All | connects participating sites to a protocol | - | CC | no/yes | - |
| Participating Site Protocol Staffing Information Manager | All | assigns internal staff to a protocol, determines which study artifacts (e.g. study calendar templates, CRFs, etc.) are accessible by each particular staff member | - | PS | no/yes | - |
| Coordinating Center AE Rule Manager | caAERS | creates and manages study-wide AE rules for a study | - | CC | yes | - |
| Participating Site AE Rule Manager | caAERS | creates and manages locally-defined AE rules for a study (can't change study-wide AE rules) | - | PS | yes | - |
| Coordinating Center AE Report Manager | caAERS | defines study-wide AE report definitions | - | CC | yes | - |
| Participating Site AE Report Manager | caAERS | defines locally-defined AE report definitions (can't change study-wide AE report definitions) | - | PS | yes | - |
| caAERS Supplemental Study Info Creator | caAERS | Adds treatment assignment codes, drugs, adEERS-specific diseases?, whether study requires adEERs reporting, CTC/MedDRA version to use, etc. | - | CC | yes | - |
| C3PR Supplemental Study Info Creator | C3PR | Update and manage registration metadata (e.g. stratifications, eligibility criteria, notifications, target accrual, multi-institutional indicator, consent form version, study randomized indicator, etc.) | Initialize Electronic Systems > Initialize Registration Systems | CC | yes | - |
| Coordinating Center Study Calendar Template Manager | PSC | creates and updates study calendar templates | Propose new use case under Plan Study: Develop patient/activity schedule (including when interventions occur, what tests are done at what time points, if there are any patient completed activities such as QOL booklet, when biospecimens need to be submitted, etc.) and new use case under Initiate Study > Initialize Electronic Systems: Initialization of study calendar | CC | yes | - |
| Coordinating Center Study Calendar Template QA/QC | PSC | does read-only review of study calendar template data, but does get to mark templates as approved and released | - | CC | yes | - |
| Participating Site Subject Manager | All | defines patient to system (remaining subject data managed by other roles) | - | PS | no | - |
| Participating Site Registration Requestor | C3PR | requests subject registration on a particular study | Conduct Study > Manage Subject > Request Subject Registration | PS | yes | - |
| Coordinating Center Study Registrar | C3PR | accepts and approves/denies subject registration requests | - | CC | yes | - |
| Subject Study Calendar Manager | PSC | creates and updates a subject-specific study calendar based on a study calendar template | Initiate Study > Open Study > Subject-Specific Study Calendar, Maintain Study Subject-Specific Study Calendar, Manage Study Subject Schedule | PS | yes | - |
| Participating Site Expedited AE Reports Initiator | caAERS | creates and updates information about an AE that needs to be reported and submits report to appropriate parties per the report definition; this role also includes the Participating Site Lab Impact Calendar Notifier role | - | PS | yes | a person with this role should also have the Participating Site lab Impact Calendar Notifier role, however that a person with that role may not have this one |
| Participating Site Routine AE Data Entry Staff | caAERS | enters set of required AEs that have to be assess and any additional AEs that the patient experienced | - | PS | yes | - |
| Participating Site Lab Impact Calendar Notifier | caAERS | creates a calendar notification for a potential lab-based treatment modification | - | PS | yes | a new caERS use case might be to include the ability to send a custom notification so CRA may order more lab studies, suggest dose or schedule modification, etc. il.e. where the CRA can define their own message |
| Lab Data User | LV | importing labs from LIMS, viewing labs, selecting and sending labs to CDMS and caAERS | - | - | - | once an authorized user has access to lab data in read-only format, they are a trusted person and are allowed to import, view, and send it to other systems - this happens on paper currently in most clinical settings and it typically done by the same person (not several different people) |
| Study Auditor | All | typically not part of the org that they are auditing, but granted temporary read-only access to a particular study (no modifications allowed), access might be to whole study or specific subjects on the study, any data entered by the site for that subject on that study, crosses all apps (i.e. registration-, AE- and possibly calendar-related data) | - | PS | yes | - |
| System Administrator | All | configure the applications | - | CC & PS | no | - |
| Custom Combination Roles | All | 2 or more other roles rolled up into a single roll that would allow user role assignment to be more efficient, defined by User Administrator | - | CC & PS | no/yes | - |
Next Steps
Presentation to CCTS Architects/Technical Leads - Completed
Following the definition of the proposed roles, the immediate next step was to present them to the CCTS architects and technical teams. This has been done they the working group and analysts involved in their development. The architects and technical staff have had a chance to review and digest the information and have asked questions which have been answered by the working group and analysts. The architects and technical staff have responded back that they have enough information to proceed with their work and will incorporate any additional roles needed due to the selection of new interoperability scenarios for CCTS 2.0 when they are identified.
These discussions between with the teams and working group/analysts also resulted in recognition of a need for a Role Management module to allow management of roles at suite level.
Support CCTS Team During Development of CCTS 2.0 - Ongoing
Following the presentation of roles to the architects and technical teams, the CCTS analysts anticipate supporting those teams as development progresses and/or questions arise. Additional roles may be required once the new interoperability scenarios for 2.0 are identified and selected for implementation by NCICB management.
BRIDG and BAM Harmonization
The CCTS Analysts will next be reviewing these roles in relation to BRIDG 2.1 and the COPPA Information model. Based on our existing knowledge of both these models, we believe the challenges lie in generalizing these system level roles into abstract business level roles that are currently present in BRIDG and COPPA.
The same applies for BAM harmonization. The CCTS Analysts are going to work with CTMSi Working Group to harmonize these system level roles of CCTS with the identified BAM roles.
The goal is to achieve harmonization of roles/actors across the dynamic models (BAM) and the static models (BRIDG) for the CTMS WS in a manner that they can be implemented by the CCTS Suite and other CTMS applications, support the security needs of DSIC as well as be domain friendly for the clinical research community.
