| Oracle® Clinical Administrator's Guide Release 4.6 Part Number A83791-06 |
|
|
View PDF |
| Oracle® Clinical Administrator's Guide Release 4.6 Part Number A83791-06 |
|
|
View PDF |
This section contains the following topics:
To create an administrator user account with which you can perform all the functions under the Oracle Clinical Admin menu:
Log on to SQL*Plus as SYSTEM and run the Add User script; see "Running the Add User Script".
Add one of the following database roles; see "Granting Additional Database Roles to User Accounts". By default, these roles have access to menus as follows:
RXC_ADMIN: Provides access to all Admin menu items.
RXC_SUPER: Provides access to all menu items.
RXC_SUPER_NOGL: Provides access to all menu items except the Global Library.
RXC_DES: Provides access to the RDC Administration tool as well as Oracle Clinical Design menu items
RXC_DMGR: Provides access to the RDC Administration tool as well as Oracle Clinical Definition and Conduct menu items
Add privileges, if required; see "Setting Up Power Users".
To add a user account to Oracle Clinical, you run the Add User script. In that script you are prompted to supply information about the servers, queues, and directories the user will use. You must either set these up in advance and enter the correct information as you run the script, or enter the information in the script and do the required setup afterward.
Set up the Reports Server; see the Oracle Clinical Installation Guide for instructions.
Determine which database roles the user needs; see Chapter 2, "Oracle Clinical Menu-Based Security"
Parameterized Submission (PSUB) user requirements. The following are required only for users who need to use the PSUB utility; see "Who Needs PSUB? ":
Who Needs PSUB? Some of the user setup tasks are required only if the user needs to be able to run Oracle Clinical's Parameterized Submission (PSUB) batch utility. PSUB is required to:
Run batch data load
Run batch data delete
Run batch validation
Generate a default, character-based DCM layout
Run the following reports: Randomization Report by Treatment, Patient DCI/DCM Matrix, Generate Study Report, Missing and Overdue DCMs, Investigator Corrs & Missing Pgs, Study/Investigator DCM Summary Matrix, Display Treatment Assignments
Run Validate Study or Validate Site in RDC—the only RDC users who need PSUB
PSUB is not required to:
Perform basic data entry in either Oracle Clinical or RDC
Generate graphic layouts and DCI forms
Run most reports, including the Patient Data and Audit History reports
PSUB initiates batch jobs on the operating system of the database server through the account of a dedicated user, RXCPROD. This account places the logs and output of the PSUB job into a directory that is accessible to the user who submits the job. Oracle Clinical users must therefore have operating system accounts on the database server.
During Oracle Clinical installation you create a Report Server root directory (see the Oracle Clinical Installation Guide for instructions). You can either use the root directory for all users' report output, or you can create a separate subdirectory for each user under the root directory. In either case, a user's access is restricted to the reports generated by that user in Oracle Clinical or RDC—regardless of whether or not there is a user-specific subdirectory.
In order for users to view reports through Oracle Clinical and RDC, enter the full path to the root directory or user-specific subdirectory when you execute the Add User script or in the Oracle Accounts window.
Note:
The full path cannot exceed 35 characters.Users who need to run PSUB (see "Who Needs PSUB? " need an operating system account on the database server. Users who want to run Data Extract jobs and SAS must also have an account on the server that runs SAS, if it is a different machine from the PSUB server.
For setting the password for a user, see "Changing the Password for a User".
When you create a user account, ensure that the path to the user's login directory does not contain uppercase characters. PSUB changes all path specifications to lowercase on UNIX platforms.
If you must have uppercase characters in the path, you can provide lowercase and uppercase versions of the paths by using symbolic links, as needed.
For example, if the standard path to user bsmith's account is:
/usr1/home/Clinical/bsmith
You can create this link:
% cd /usr1/home % ln -s Clinical clinical
Create a PSUB root directory on the database server and user-specific log subdirectories for users who need PSUB. When a PSUB batch job runs, the system writes the log and output files associated with the job to the log directory of the user who ran the job.
UNIX On UNIX servers, Oracle suggests you create a directory named log as a subdirectory of each user's home directory. For example, for user bsmith
/u01/home/bsmith/log
Windows On Windows servers, Oracle suggests you create a directory named oc_users, and beneath that create a subdirectory for each user, which is named for that user. In each user-specific directory, create a log subdirectory.
You must give each user read/write access to their directory.
For example, for user bsmith:
d:\oc_users\bsmith\log
Each user has a PSUB log directory under the PSUB root directory. Therefore the root directory must be accessible to all users. In the previous examples, the shared PSUB root directories are "/u01/home" (UNIX) and "d:\users" (Windows). In addition, the root directory must be accessible to the Oracle Clinical middle tier. You do this differently, depending upon whether you choose the UNC or HTTP protocol, as described below.
FTP Protocol If you chose FTP as the file viewing protocol, you can skip this step.
UNC Protocol If you chose UNC as the file viewing protocol, you must create a UNC for the PSUB root directory and make the PSUB root directory readable by the network domain account that is used to start the application server.
HTTP Protocol If you chose HTTP as the file viewing protocol, you must set up the PSUB root directory as a virtual directory on the Web Server. Generally, you would setup that Web Server on the same computer as the PSUB root directory. Oracle Database ships with an Oracle HTTP Server that you can use as a Web Server.
Note:
Refer to "Setting Up File Viewing" for additional information.On UNIX database servers, the PSUB utility works by having one operating system account, RXCPROD, use rsh (remsh on HP-UX) to submit batch jobs on behalf of the actual user's operating system account. To submit these jobs on the user's behalf, RXCPROD must have permission to access the user's account. You can grant this permission either: through an entry in /etc/hosts.equiv, which grants RXCPROD the permission for all users, including new users as they come to be created, or through an entry in each account's .rhosts file.
For all users at once: If the database server has an /etc/hosts.equiv file, add official_host_name rxcprod as a line in the file. This grants RXCPROD the permission for all users, including new user accounts as they are created.
For each user individually: Create a file named rhosts in the user's login directory and include official_host_name rxcprod as a line in the file.
where official_host_name is the official name of the computer on which you are installing Oracle Clinical. You must use the official name — not an alias — for the server. The official name is the first listing after the IP address in the /etc/hosts file.
RXCPROD is the dedicated PSUB account. Enable RXCPROD to find the programs that PSUB runs by doing the following:
Open the RXCPROD account's .profile file and edit the PATH command:
PATH=$PATH:opapps_home/bin:oracle_home/bin
where oracle_home is the path of the Oracle home directory and opapps_home is the path of the Oracle Clinical home directory.
Create a database account for the user in each database instance to which the user connects by running the script ocl_add_user.sql in SQL*Plus.
This section contains the following topics:
The ocl_add_user.sql script performs the following tasks:
creates an Oracle database account for the user, with the specified password
Note:
If you use SQL*Plus to create a Oracle Clinical database account, do not use the IDENTIFIED EXTERNALLY clause; rather, assign an explicit password.sets the user's temporary tablespace to "temp" and default tablespace to "users"
grants default Oracle Clinical database roles to the user; you can edit the script to assign additional database roles
grants the RXC_SUPER role for data access to all studies, if specified
grants RXC_RDC and RDC_ACCESS if access to RDC is required
makes the RXCLIN_MOD role a non-default role
creates a record in the Oracle Clinical table ORACLE_ACCOUNTS.
Note:
You can copy and customize this script, or create different versions of it for different types of users. For example, you can change temporary and default tablespaces, provide default values for some parameters instead of entering a value for each user at a prompt. You can add a call to crusrq.sql to create the USER_QUERIES table (see "Creating a Queries Table for a Data Extract User").However, if you decide to customize the script, it is important not to modify the line: alter user &&ops_id default role all except rxclin_mod;
Note:
You can give users additional database roles directly in SQL*Plus; see "Granting Additional Database Roles to User Accounts".Log on with your UNIX account.
Set the environment.
For UNIX servers, C shell, enter the following:
opa_setup database_instance_name code_environment_designation
For example: %opa_setup burlma9 22
For UNIX servers, Bourne shell, enter the following:
p1 = database_instance_name p2 = code_environment_designation opa_setup
Change to the RXC_TOOLS directory:
cd $RXC_TOOLS
Call SQL*Plus and log in as SYSTEM:
sqlplus system
Run the Add User script:
start ocl_add_user.sql
See Table 1-1, "Add User Script Required Parameters" and Table 1-2, "Add User Script Optional Parameters" for a description of the prompts output by the Add User script, valid entries, and examples.
Log on with your local account.
Open an MS-DOS window.
Set the server environment:
set p1=db_nameset p2=code_envopa_setup
where db_name is a database instance name and code_env is a code environment designation.
Change to the RXC_TOOLS directory:
cd %RXC_TOOLS%
Call SQL*Plus and log in as SYSTEM.
sqlplus system
Run the Add User script:
start ocl_add_user.sql
The following table describes the required Add User script parameters:
Table 1-1 Add User Script Required Parameters
| Prompt/Equivalent in Oracle Accounts Window | Description | Rules and Examples |
|---|---|---|
User ID, starting with OPS$ /Account Name |
Defines the login name for the user. Names are not case sensitive.
If |
OPS$bsmith bsmith |
Password Not in the Oracle Accounts window |
Defines the login password for the user. Passwords are not case sensitive. See "Changing the Password for a User". |
farrier |
Last Name /Last Name |
Specifies the user's surname (family name). Names are not case sensitive; names are automatically capitalized. |
Smith |
First Name First Name |
Specifies the user's given name. Names are not case sensitive; names are automatically capitalized. |
William |
PSUB Log Directory /PSUB Directory |
Specifies the directory where PSUB places output and log files from PSUB jobs. See "Who Needs PSUB? ". RDC users need a PSUB log directory only if they run Validate Study or Validate Site. You create the root directory during installation. |
UNIX: Windows (use UNC): |
Report Server Log Directory /Report Server Directory |
Specifies the designated location for saving output from the Report Server. Required for generating and viewing Patient Data Reports and most Oracle Clinical reports. You create the directory as part of setting up the Report Server during Oracle Clinical installation. |
Must be specified in UNC format. String length cannot exceed 35 characters. \\oc_srvr\users\bsmith |
Grant RXC_Super Menu Role (Y/N) Not in the Oracle Accounts window |
Specifies whether to grant superuser menu privileges to this user. With this privilege, the user can access all Oracle Clinical menus. In general, Oracle recommends that you restrict the RXC_SUPER role to system administrators. This setting does not correspond to a field in the Oracle Clinical accounts table. |
Y — Gives superuser menu privileges to this user. N — Does not give superuser menu privileges to this user. You should always answer N for non-Oracle Clinical users. |
Grant Super-User Status to access all studies (Y/N) /Super User? |
Specifies whether to grant superuser status to this user. With this privilege, the user can access all clinical studies in the database, in both Test and Production modes. This setting corresponds to the Super User? check box in the Oracle Clinical accounts table. You can change this setting and grant access to programs, projects, and studies in the Oracle Accounts window; see "Granting Data Access to User and Group User Accounts". |
Y — Allows this user to access all clinical studies. N — By default, the user does not have access to any studies. You must explicitly grant access to particular studies, projects, or programs. |
Does user require access to RDC (Y/N) Not in the Oracle Accounts window |
Specifies whether this user can log in to and use the RDC Onsite application. A Y value grants the RDC_ACCESS and RXC_RDC roles to the user. The RDC_ACCESS role lets the user initiate an RDC Onsite session and the RXC_RDC role lets the user enter and modify data (subject to study- and site-level security privileges). |
Y — Lets this user access the RDC Onsite application. N — Denies access to the RDC Onsite application for this user. |
The remaining parameters are optional. In addition, you can use the Maintain Oracle Accounts form to manage these optional parameters; see "Maintaining Oracle User and Group User Accounts".
Table 1-2 Add User Script Optional Parameters
| Prompt/Equivalent in Oracle Accounts Window | Description | Rules and Examples |
|---|---|---|
|
/Custom Help Directory |
Specifies the location of your site-specific context-sensitive HTML help files. |
|
|
/Default PSUB Printer |
The printer to which PSUB print jobs are routed, in upper case. This response must match the Short Value of an active entry in the PRINT QUEUE NAME local reference codelist. Required for RDC users only if they run Validate Study or Validate Site. |
|
|
/Default PSUB Queue |
The designation for the queue in which PSUB batch jobs are executed. This response must match the Short Value of an active entry in the BATCH QUEUE NAME local reference codelist. Must be entered in upper case. Required for RDC users only if they run Validate Study or Validate Site. |
|
|
/Default RS Printer |
The printer to which print output from a report server job is routed. This response must match the Short Value of an active entry in the PRINT QUEUE NAME local reference codelist. Must be entered in upper case. |
|
|
/Default Report Server |
Specify a value if you want to override the system default for a specific user. When the user prepares to submit a report request, this response specifies which report server is offered as the default. This response must match the Short Value of an active entry in the REPORT_SERVER local reference codelist. |
|
|
/Default Job Set Server |
When the user prepares to submit a job set request, this response specifies which report server is offered as the default. This response must match the Short Value of an active entry in the REPORT_SERVER local reference codelist. Required for RDC users only if they run Validate Study or Validate Site. |
|
|
/Default PSUB Scheduler Report Server |
When the user prepares to submit a scheduled PSUB job request, this response specifies which report server is offered as the default. This response must match the Short Value of an active entry in the REPORT_SERVER local reference codelist. Required for RDC users only if they run Validate Study or Validate Site. |
|
After you create a user with the Add User script, the user account appears in the Oracle Accounts window. Use this window to:
Create group user accounts
View and modify settings for individual user accounts
Do not use this window to create new individual user accounts because you cannot assign database roles to users here. Use the Add User script.
You can access other windows from Oracle Accounts to do the following tasks:
Adding a User to a Group User Account; use this window to assign a user to a group user account. You can then grant data access to all the users assigned to the group user account at the same time.
Granting Data Access to a Study; use this window to grant access to one study at a time to a single user or group user account
Granting Data Access to Programs and Projects; use this window to grant a access to all the studies in a program or project at the same time to a single user or group user account
To create a group user account:
From the Data menu, select Insert Record.
Enter values in the fields.
The window contains the following fields:
Account Type If set to Oracle, the record is an individual user account. To create a group user account, set to Group.
Account Name For an individual user account, the user ID; for a group user account, its name.
Last Name Family name or surname of the user with the individual user account; not required for group user accounts.
First Name Given name of the user with the individual user account; not required for group accounts.
Super User? If checked, the user or group user account has superuser status and can see data in all studies on the database. If not checked, the user or group user account can see data only for studies to which they are explicitly allowed access; see "Granting Data Access to User and Group User Accounts".
PSUB Directory Location for log and output files from Parameterized Submission jobs; see "Creating a PSUB Log Directory".
Report Server Directory Location for log and output files from Oracle Clinical reports jobs; see "Setting Up a Report Server Log Directory".
Note:
The location designation for any report server log directory, whether directory path or UNC, cannot exceed 35 charactersCustom Help Directory Location of company-specific context-sensitive html files, if any.
Default PSUB Printer The printer to which PSUB print jobs are routed, in upper case. This response must match the Short Value of an active entry in the PRINT QUEUE NAME local reference codelist.
Default RS Printer The printer to which print output from a report server job is routed. This response must match the Short Value of an active entry in the PRINT QUEUE NAME local reference codelist. Must be entered in upper case.
Default PSUB Queue The designation for the queue in which PSUB batch jobs are executed. This response must match the Short Value of an active entry in the BATCH_QUEUE_NAME local reference codelist. Must be entered in upper case.
Default Report Server When the user prepares to submit a report request, this response specifies which report server is offered as the default. This response must match the Short Value of an active entry in the REPORT_SERVER local reference codelist.
Default Job Set Report Server When the user prepares to submit a job set request, this response specifies which report server is offered as the default. This response must match the Short Value of an active entry in the REPORT_SERVER local reference codelist. See "Using Job Sets to Control Execution Order" for information on job sets.
Default PSUB Scheduler Report Server When the user prepares to submit a scheduled PSUB job request, this response specifies which report server is offered as the default. This response must match the Short Value of an active entry in the REPORT_SERVER local reference codelist.
|
Note: The location designation for any report server log directory, whether directory path or UNC, cannot exceed 35 characters. |
You can add all the users who should have access to the same set of studies, programs, or projects to the same group user account and assign data access to all the users at the same time through the group user account. An individual user can belong to multiple group user accounts.
To add a user to a user group:
Navigate to Admin, Users, and then Oracle Accounts. The system opens the Oracle Accounts window.
Query for the individual user you want to add to a user group.
Click Group Membership. The system displays the Group Membership window.
From the Group Membership field's list of values, select the group to which you want to assign the user. If you want to assign the user to multiple user groups, use multiple rows.
Save your work.
You must explicitly give users access to study data, either by granting them Superuser status, which allows access to all studies, or explicitly granting access to specific studies or groups of studies (programs and projects). For RDC users, you can use either the Oracle Accounts window or the Study and Site Security windows; see "Granting Data Access to RDC Users".
To allow an Oracle Clinical or RDC user—even a user who will work exclusively in RDC—to view study data, you must grant study or superuser access in Oracle Clinical. You can grant data access to a user or group user account in several ways:
Grant access to data in all studies by granting the user or group user account superuser status, either in the Oracle Accounts window or, for individual users, when you run the Add User script.
If the user or group user accounts does not have superuser status, you can grant access to data in one or more studies, either to one study at a time or to all studies in a program or project.
You can grant data access at several levels:
See also "Superuser and Study Access Interaction" and "Revoking User Access".
Assigning program or project access to a user or group user account enables either the individual user or the set of users in the group to have access to all studies associated with the program or project.
Navigate to Admin, Users, and then Oracle Accounts. The system opens the Oracle Accounts window.
Query for the account with which you want to work.
Note:
You cannot assign project or program access to a user or user group whose Super User? flag is checked. That account already has access to all programs and projects.Click Programs/Projects. The Programs window displays.
In the Program field, from the list of values select the name of the program to which you want the user or user group to have access.
In the Project field, from the list of values select the program to which the user will have access. If the user should have access to all projects within a program, enter a percent sign (%) in the project field.
If you want to assign multiple programs to the account, or multiple (but not all) projects within a program, use multiple rows. There is no limit to the number of programs to which the user can have access.
To assign study data access to a user or user group:
Navigate to Admin, Users, and then Oracle Accounts. The system opens the Maintain Oracle Accounts window.
Query for the account with which you want to work.
Note:
You cannot assign study access to a user or user group whose Super User flag is checked. That account already has access to all studies.Click Studies. The Studies window displays.
In the Study field, from the list of values select a study to which you want the user or user group to have access. If you want to assign multiple studies to the account, use multiple rows. There is no limit to the number of studies you can specify.
Save your work.
Note:
If a user creates a new study and does not have access to it through the project and/or program it belongs to, the system automatically gives the user access to the study he or she has just created.You cannot assign project or program access to a user or user group whose Super User? flag is checked. That account already has access to all programs and projects.
However, if you assign access to programs, projects, or studies to a user whose Super User? flag is not checked, and then check that user's Super User? flag, the superuser status overrides the existing specific privileges, but the existing privileges are still displayed in the Projects, Programs, and Studies windows.
If an RDC user has superuser status in the Oracle Accounts window and has access to only a subset of RDC studies in the Study Security window, the superuser status overrides the study-specific privileges and the user has access to all studies. However, you can use the Study Security window to limit the type of access to a particular study. See the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for information.
Note:
If a user has both superuser status and access to specific studies defined, you must revoke the superuser status before you can revoke his/her access to a specific study.When you revoke access to a program, you revoke access to all projects within that program.
To revoke a user's study, user group, project, or program access:
Navigate to Admin, Users, and then Oracle Accounts. The system displays the Oracle Accounts window.
Query for the account with which you want to work.
Click either Studies, Programs/Projects, or Group Membership.
Select the study, program/project combination, or user group from which you want to remove the user.
From the Data menu, select Delete Record.
Save your work.
This section contains the following topics:
You can use a reference codelist setting to determine whether users who have access to data for a particular study in Oracle Clinical automatically have access to the study in RDC.
In the OCL_STATE local reference codelist, set the DMGR RDC ACCESS short value as follows:
When set to YES, a user with no study privileges defined for RDC but with study access defined in Oracle Clinical is automatically given RDC Onsite access to the study as well, in both Test and Production modes. The user has all RDC privileges except APPROVE and VERIFY. UPD_LOCK_OC. an Oracle Clinical-specific privilege, is also excluded. You can restrict such a user's access to RDC Onsite by limiting privileges at the study or site level; see the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for further information.
When set to NO, a user granted access to a study in Oracle Clinical does not automatically have access to that study in RDC Onsite. You can use the Study Security form to assign specific privileges to the user; see the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for further information.
Users with the Super User? flag selected in the Oracle Accounts form in Oracle Clinical have access to all studies in both Oracle Clinical and RDC, and in both Test and Production modes.
You can give RDC users specific privileges for particular studies and sites in the Study and Site Security windows, which are included in both Oracle Clinical and in the RDC Onsite Administrator's Tool; see "Configuring Study and Site Security for Discrepancy Management".
RDC Onsite includes a predefined set of user roles. By default, these roles have UNRESTRICTED access to all DCIs. You can change the default access for any role to RESTRICTED.
Users assigned to a role with UNRESTRICTED access to DCIs can access any DCI in RDC Onsite unless access has been denied to a particular DCI in a particular study through the DCI Access window in the Oracle Clinical Definition menu; see Oracle Clinical Creating a Study for study-level information.
Users assigned to a role with RESTRICTED access to DCIs cannot access any DCIs in RDC Onsite unless access has been granted to a particular DCI in a particular study.
You may want to create custom database roles specifically for the purpose of restricting access to certain DCIs to smaller groups of people (see "Creating Custom Database Roles" for more information and an example). If you do, you must add the new role in the Maintain DCI Access by Role window and specify a default access of RESTRICTED or UNRESTRICTED for it.
Caution:
If you create a new user role but do not specify a default value for DCI access, users assigned to that role cannot log in to RDC Onsite. You must define the default access to DCIs for every user role you plan to assign.If you assign a user to more than one role, and those roles have conflicting DCI access, the user cannot log it to RDC Onsite.
Before you can change the default DCI access for a user, the user role must exist (must be valid). You cannot change the default DCI access if the user role does not exist.
To define the DCI access for a user role:
Open Oracle Clinical.
Navigate to Admin and then select Users and Roles.
Select Default DCI Access by Role.
Alternatively, you can select one of the following menu options depending upon your administrator privileges and current task:
Select Test Default DCI Access if you want to try out DCI access before implementing the feature in a live study.
Select Query Default DCI Access by Role if you only want to view the current settings but make no changes.
Enter a valid user role in the User Role field. You can:
Type the name of a valid user role into the field.
Click the List of Values button, and then select a user role from the list. The list includes all the user roles currently defined in the USER GROUP ROLES installation reference codelist.
Enter the default DCI access for the selected user role. Valid entries are:
UNRESTRICTED — Allows study/site access to all DCIs unless otherwise restricted in the DCI Access form for the study.
RESTRICTED — Does not allow access to any DCIs unless you specify exceptions in the DCI Access form for the study.
You can type a valid entry directly into the field. Alternatively, you can click the List of Values button, and then select from the list.
Continue to enter each user role and the type of DCI access allowed.
Save your changes.
For each record in the Maintain Default DCI Access by Role form, Oracle Clinical creates and maintain an audit trail.
Upon initial entry to the form, Oracle Clinical populates the form with all the user roles defined in the USER GROUP ROLES reference codelist. For each user role, the Default DCI Access field is set to UNRESTRICTED. You must add any new user roles that you create.
This section contains the following topics:
The Add User script grants the minimum database roles required for a user to access Oracle Clinical and, if you specify that RDC access is required, RDC.
Oracle Clinical default database roles: CONNECT, RESOURCE, RXCLIN_READ, RXC_ANY, AND OCL_ACCESS
RDC default database roles: RXC_RDC and RDC_ACCESS
Users require additional database roles to do meaningful work in either Oracle Clinical or RDC.
To grant one or more database roles to a user:
Log in to SQL*Plus as SYSTEM.
Grant a role to a user:
grant database_role to user_name
For example: grant rxc_site to BSMITH
You must explicitly grant every RDC Onsite user at least one database role. You can use the predefined database roles listed in Table 1-3, selecting the role that matches the user's job function, or define additional database roles if you need to further fine-tune security privileges; see "Creating and Modifying Database Roles".
These database roles are mapped to user roles in the installation reference codelist USER_GROUP_ROLES. Those user roles are used to define security privileges and to customize various aspects of the user interface. See Chapter 3, "Configuring Discrepancy Management" for further information.
Table 1-3 Default Database Roles Defined for RDC Users
| Database Role | Typical User Profile |
|---|---|
|
RXC_DMGR |
Data manager |
|
RXC_SUPER |
Data manager |
|
RXC_CRA |
Clinical Research Associate (CRA) |
|
RXC_SITE |
Site user, study coordinator, or other person at the remote site responsible for entering patient data |
|
RXC_INV |
Investigator at the remote site who can approve CRFs |
The database roles assigned to a user determine which tasks a user can perform by controlling which menu paths the user can see in the user interface—for example, Study Design, Data Entry, or Administration—and within those areas, finer distinctions such as whether the user can make changes or only view existing data. Oracle Clinical includes many predefined database roles for this purpose. You can also define your own database roles; see Chapter 2, "Oracle Clinical Menu-Based Security" for more information.
The roles in Table 1-3 apply to the Oracle Clinical discrepancy management system as well as to RDC. Give one of the above roles to each user who has one of the corresponding job functions and who will be working with discrepancies in Oracle Clinical's Maintain Discrepancy Database window.
Oracle Clinical users who need to generate Data Extract views and write macros require additional setup:
User who need to generate SAS Data Extract view need an operating system account on the SAS server. If they do not already have one, create one; see instructions in "Creating an Operating System Account".
Add the user to the OCLSASCR user group to give the user access to the RXC_USER directories that hold the SAS Data Extract Views. The OCLSASCR user group is created as part of the Oracle Clinical installation and has all the privileges required to use SAS. Refer to the Oracle Clinical Installation Guide for instructions on creating the OCLSASCR group.
You can add the user to the OCLSASCR user group by:
using the usermod command, or
editing the /etc/group and /etc/logingroup files, if these files are not linked; if these files are linked, it is only necessary to modify the /etc/group file.
Oracle provides a script, crusrq.sql, that creates a table called USER_QUERIES in an individual user's schema. The table provides a location to save the SQL code the user creates using data extract functions. Run the script for each user who will write data extract functions.
To create this table:
Change directories to the RXC_INSTALL directory.
Run this command:
sqlplus @crusrq
Alternatively, you can modify the Add User script to create the USER_QUERIES table automatically by adding these lines:
connect &&ops_id/&&pwd @rxc_install:crusrq.sql
Most end users do not require additions to a login script for Oracle Clinical purposes. Only power users who want to run opa_setup from the command line (in order to condition their environment to point to a particular database, or a code environment, or both), must add commands to a login script on that machine, in order to configure their environments.
A power user might use opa_setup to set environment variables for such tasks as:
running client applications other than Oracle Clinical (such as SQL*Plus, SAS, or a reporting program) against an Oracle Clinical database
installing patches to Oracle Clinical server code or databases
running Oracle Clinical administrative SQL scripts
For users who will perform these tasks, commands must be added to the login scripts that:
define RXC_LOG
add SAS
add source (on C shell).
Bourne/Korn shell Edit the user's .profile file. In the following example, SAS_home is the directory where the SAS executable is located.
# Include OPA directories PATH=$PATH:/opa_home/bin:/sas_home; export PATH # Define RXC_LOG for command line utilities RXC_LOG=$HOME/log; export RXC_LOG
C shell Edit the user's .cshrc file. For example:
# Include OPA directories set path=( $path /opa_home/bin /sas_home ) # Define RXC_LOG for command line utilities setenv RXC_LOG $HOME/log # Create alias for opa_setup source /opa_home/bin/copa_setup_alias
Changing passwords depends on whether they are for a schema, a role, or for a user.
The section is comprised of the following topics:
Certain Oracle Clinical database objects are protected by password. These objects are listed and described in Table 1-4, "Password-protected database objects".
Table 1-4 Password-protected database objects
| Name | Type | Description |
|---|---|---|
|
Schema |
Required for Data Extract. |
|
|
Schema |
Required for Procedure generation. |
|
|
Schema |
Required for replication. |
|
|
Schema |
Required for disconnected replication. |
|
|
Role |
Enables Oracle Clinical users to write to the database. This role is set for users when they log in through the application. |
|
|
RXC_SERVLETSP |
Schema |
Used for accessing study data from Data Entry window in Production mode. |
|
RXC_SERVLETST |
Schema |
Used for accessing study data from Data Entry window in Test mode. |
Encrypted versions of the passwords associated with these objects are stored in two locations:
an Oracle dictionary table, and
an Oracle Clinical passwords table.
If you want to change any of these passwords, you must change the encrypted value in both locations. You can change the passwords in both places at once with the SET_PWD utility, following these steps:
Log on to the database server using an account that is set up to run Oracle Clinical back end jobs.
Set environment variables for the database and code environment. For example, for database test and code environment 46:
UNIX: opa_setup test 46
Windows:
Enter a command in the following format:
set_pwd rxc/rxc_password db_object_name db_object_password
where rxc_password is the password for the rxc account, db_object_name is the name of the database object from Table 1-4, "Password-protected database objects", and db_object_password is the new password for that object. For example:
set_pwd rxc/notrxc rxclin_mod r2d2c3po
Users can change their own database passwords either in SQL*Plus or with the Oracle Clinical menu by choosing Admin, then Users, and then Database Password.
In the Oracle Database Password window:
Type your password in Enter Password text box.
Type it again in the Confirm Password text box.
Click OK.
Administrators can change the password for an Oracle Clinical user in SQL*Plus as usual:
In SQL*Plus, connect to the database as the SYSTEM user.
Reset the password for the user:
alter user user identified by user_password;
Oracle enables a database administrator to enforce various rules about passwords at the database level, including setting a password lifetime, after which users must set a new password; disallowing reuse of previous passwords; locking an account after a user attempts to logon a specified number of times; and creating complexity rules for passwords through a PL/SQL function.
All rules that you set at the database level apply when a user connects through Oracle Clinical. If the password has expired, a dialog box that prompts the user for a new password automatically appears. For further details, refer to your Oracle Administrator's Guide.
Oracle recommends that you turn on the auditing system for roles. For information on the AUDIT command, refer to the Oracle SQL Reference manual.
To track failed attempts to create, alter, drop, or set a role, issue the following statement:
audit role by access whenever not successful
A system-level account must exist on the database server computer in order for Oracle Clinical users to run PSUB jobs. On UNIX, you can choose whether to allow users to store their UNIX account passwords in the Oracle Clinical database in an encrypted format. On Windows, users must store their passwords to be able to run any PSUB job.
You use the Operating System Password window to change whether your system password is stored in Oracle Clinical. This window is accessible either:
by selecting Admin, then Users, and OS Password, or
by selecting the Server OS Password button in the Submission Details window.
The Operating System Password window consists of an Enter password text box and a check box entitled, Save encrypted password in the database?
The behavior of the check box depends on your operating system and is described in the following subsections:
Note:
If the PSUB server belongs to a Windows domain, users' local accounts on that server must match the passwords of their domain accounts. In this way, the correct authentication is passed to the server and access is allowed to the domain resources. Otherwise, users' PSUB jobs do not print.On UNIX servers, you control the Save encrypted password in the database? check box with the Short Value of the USR_SAVE_OSPASS entry in the OCL_STATE local reference codelist. The default value of USR_SAVE_OS_PASS is "N" (No). In this case, the check box the system displays in the Operating System Password window is clear and not updateable. If you change the value of USR_SAVE_OS_PASS to "Y" (Yes), the check box is still clear, but it is updateable, which allows the user to select it.
On Windows servers, a stored password is required for any PSUB server-side job. When end users see the Server OS Password dialog box, the Save encrypted password in the database? check box is selected and cannot be updated. The first time a user runs a PSUB job, the system prompts for a password if it has not already been stored in the database.
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
