About Security Privileges

You can use the RDC Administration application to assign privileges. You can assign one privilege or a set of privileges to a user.

Privileges give RDC users the permission to perform a certain task or an action for a specific study or study site. For example, you may give some users the right to browse (view) data, but not update data. Other users may receive the privilege to update, verify, and approve CRFs.

Privileges are independent of user roles. However, you often assign the same set of privileges to all users in a particular role.

You can assign privileges on a study basis or a study site basis. For example, you can grant a user BROWSE access to all sites in the study, and then grant the same user UPDATE privileges for one site. See the table in Minimum Requirement for Privileges for descriptions of the privileges you can assign to users.

Note:

Some privileges also apply to Oracle Clinical users who have access to the Discrepancy Management form.

For more information, see the Configuring Discrepancy Management section in the Oracle Clinical Administrator's Guide.

For more information, see:

Minimum Requirement for Privileges

All users must be assigned at least one privilege in order to start a RDC session. If RDC determines at login that the user is not assigned at least one privilege, the login fails and the session does not start.

The minimum privilege you can assign is the BROWSE or BRW_BATCH privilege. However, all other privileges also include the BROWSE privilege. Therefore, you only need to grant the BROWSE privilege to users who will have no other privilege.

Note that BROWSE does not include BRW_BATCH.

Note:

In addition to granting privileges, you must grant a role to each user.
Privilege Access Granted Applies To…

BROWSE

Provides read-only access to manually-entered data.

The BROWSE privilege does not include the privileges defined by BRW_BATCH, BROWSE_REVIEW, BROWSE_VERIFY or BROWSE_SDVPLAN.

  • RDC

  • Oracle Clinical Discrepancy Management form

BRW_BATCH

Provides read-only access to batch-loaded data.

The BRW_BATCH privilege does not include the privileges defined by BROWSE_VERIFY, BROWSE_REVIEW or BROWSE_SDVPLAN.

  • RDC

  • Oracle Clinical Discrepancy Management form

BROWSE_VERIFY

Provides read-only access to CRF VERIFICATION status. Also provides visibility into CRF verification requirement status when Partial Source Data Verification is being used.

This privilege is required to be able to search for CRFs based on verification status or verification requirement status and to view metrics regarding CRF verification status. These functions are only included in the VERIFY, BROWSE_SDVPLAN, and UPDATE_SDVPLAN privileges, as well as the BROWSE_VERIFY privilege.

  • RDC

BROWSE_SDVPLAN

Provides read-only access to SDV plan.

The BROWSE_SDVPLAN privilege includes the privileges defined by BROWSE and BROWSE_VERIFY.

  • RDC

BROWSE_REVIEW

Grants read-only access to view CRF status in terms of all the custom review types defined and in use for your study.

For more information on defining Custom Review Types, see Configuring Custom Review Types

  • RDC

Update privileges for custom review types

The update privilege for a custom review type allows the user to update the CRF status for that review type.

You create the update privilege for each custom review type when you define the review types for your installation. See Configuring Custom Review Types for more information.

  • RDC

UPDATE

Lets the user enter data into a CRF, update manually-entered data, and update discrepancies.

The UPDATE privilege includes the privileges defined by UPD_DISCREP.

However, the UPDATE privilege does not include the privileges defined by UPD_BATCH.

  • RDC

  • Oracle Clinical Discrepancy Management form

UPD_BATCH

Lets the user update data, initiate discrepancies, and update discrepancies in CRFs that are batch-loaded.

The UPD_BATCH privilege includes the privileges defined by BRW_BATCH.

  • RDC

  • Oracle Clinical Discrepancy Management form

UPD_DISCREP

Lets the user initiate or update a discrepancy in CRFs that are manually entered as well as batch-loaded.

  • RDC

  • Oracle Clinical Discrepancy Management form

UPDATE_SDVPLAN

Lets the user update SDV plans.

The UPDATE_SDVPLAN privilege includes the privileges defined by BROWSE_SDVPLAN and BROWSE_VERIFY.

  • RDC

ADMIN_SDVPLAN

Lets the user unlock a plan that another user left unlocked.

The ADMIN_SDVPLAN privilege includes the privileges defined by BROWSE_SDVPLAN

  • RDC

VERIFY

Lets the user electronically confirm that the source data has been verified.

The VERIFY privilege includes the privileges defined by BROWSE_SDVPLAN and BROWSE_VERIFY.

However, the VERIFY privilege does not include the privileges defined by UPDATE_SDVPLAN.

Users with this privilege have access to the tools for verifying CRFs.

  • RDC

APPROVE

Lets the user electronically sign CRFs.

Users with this privilege have access to the tools for approving CRFs.

Note: You can grant this privilege at the site level only.

  • RDC

UPD_LOCK_OC

Assigns privileged update to the user, and lets the user update locked documents in Oracle Clinical.

  • Oracle Clinical only

Privileges and Batch-Loaded CRFs

Batch-loaded CRFs are a distinct type of CRF. For any user who needs to view or update batch-loaded CRFs, you must assign one of the following separate privileges:

  • BRW_BATCH
  • UPD_BATCH

The VERIFY and APPROVE privileges are the same for batch-loaded and manually-entered CRFs. However, a user with VERIFY or APPROVE privileges must also have either the BRW_BATCH or the UPD_BATCH privilege to open and view a batch-loaded CRF.

In addition, the UPD_BATCH privilege only lets you update response data and investigator comments in a batch-loaded CRF.

Users with UPDATE and UPD_BATCH privileges can create or update responses and discrepancies for batch-loaded and non-batch-loaded CRFs.

Users with BRW_BATCH and UPD_DISCREP privileges can create or update discrepancies but not responses for a batch-loaded CRF.

Users with BRW_BATCH and UPD_BATCH (and no UPDATE) can see batch-loaded CRFs in Browse mode only.

Site Privileges Take Precedence Over Study Privileges

For RDC, you can assign any privilege at either the site level or the study level except for the APPROVE privilege. You can assign the APPROVE privilege at the site level only.

Privileges granted at the site level take precedence over privileges granted at the study to which the site belongs. This hierarchy gives you the flexibility to grant a user privileges that are more extensive at one site and still let that user access data at other sites within the same study.

  • UPDATE at the study-level, and
  • UPDATE and APPROVE at Site001 and Site 002

The following table lists sample sets of privileges typically granted to different roles. Note that certain privileges are granted at the study level, while other privileges are granted at the site level (that is, on a site-by-site basis).

Job Study Level Site Level

Investigator

BROWSE

APPROVE

Data entry personnel

UPDATE, BRW_BATCH

CRA

BROWSE, BRW_BATCH

UPD_DISCREP, VERIFY

Data manager

BROWSE, BRW_BATCH, UPD_DISCREP

Example 2-1 Using Site- and Study-Level Privileges to Limit Access

Suppose a study has Site001 through Site006. If you want to let a user UPDATE data at all sites except Site003, assign the following privileges to that user:

  • UPDATE privilege at the study level
  • BROWSE privilege for the Site003 site

Because privileges at the site level take precedence over those at the study level, BROWSE is the only privilege that has affect at Site003. This setup effectively limits the user to view-only access to all CRFs associated with patients assigned to Site003.

Example 2-2 Assigning Site- and Study-Level Privileges to Provide Full Access

Suppose a study has Site001 through Site006. If you assign a user the UPDATE privilege at the study level, the user can update data and discrepancies at all sites in the study. If you then assign the user a site-level APPROVE privilege for Site001 and Site002 only, the user can APPROVE CRFs at those two sites, but cannot UPDATE data at those two sites. The site privilege takes precedence over the study privilege.

To allow the user to update data at all sites in the study, you must assign the user site-level UPDATE, as well as APPROVE privilege, at Site001 and Site002: