| Oracle® Clinical Development Analytics User and Administrator Guide Release 2.0.0.2 Part Number E18162-03 |
|
|
View PDF |
| Oracle® Clinical Development Analytics User and Administrator Guide Release 2.0.0.2 Part Number E18162-03 |
|
|
View PDF |
This chapter contains the following topics:
Oracle Clinical Development Analytics (OCDA) spans several applications: Oracle Clinical and Oracle's Siebel Clinical are the data sources, Oracle Life Sciences Data Hub (Oracle LSH) loads and stores the data, and Informatica ETL Programs stored in Oracle LSH transform Oracle Clinical and Siebel Clinical data structures into the star schema required by Oracle Business Intelligence Enterprise Edition (OBIEE), which reads from the star schema and provides the user interface where end users can view and analyze data through dashboards and reports.
You perform almost all security tasks in Oracle LSH.
OCDA security includes:
Authentication. OCDA user accounts are maintained in Oracle Life Sciences Data Hub (Oracle LSH). When a user logs in to OBIEE, OBIEE sends the user name and password to Oracle LSH for authentication. For more information, refer to Setting Up User Authentication.
Authorization. You assign user accounts to user groups in Oracle LSH. On login, Oracle LSH passes the authenticated user's user group assignments to OBIEE, where user groups with the same name determine which parts of OCDA the user can use.
Predefined OBIEE user groups determine the privileges allowed to users and allow access to the shipped OCDA dashboards and reports. You must define an Oracle LSH user group with the same name for each OBIEE user group you plan to use. You can create additional user groups as needed in both OBIEE and Oracle LSH. In addition, in Oracle LSH you must define roles, assign the roles to user groups, and assign users to roles in user groups. For more information, refer to Setting Up User Authorization.
Data Access. In OCDA, study-level data means planned sites, documents, and enrollment, and study site-level data means all other OCDA data. You can allow all users to see study-level data from all studies and study site-level data from all study sites, or you can require explicit access to particular studies and study sites for each user. You may need to create Oracle Clinical or Siebel Clinical user accounts in order to explicitly control access by OCDA users to Study and Study-site level data. For more information, refer to Setting Up Study and Study Site Data Access for Users.
Figure 6-1 Study and Study Site Security Implementation
This document describes how to set up security for the following basic types of users as an example. To refine this example for your company's needs, refer to the Oracle LSH System Administrator's Guide chapter on setting up security.
OCDA End Users are people who can view Oracle Clinical and Siebel Clinical data in OCDA through dashboards and reports. The specific dashboards and reports they can view is determined by the user groups they belong to.
OCDA Programmers are people who are authorized to create their own reports in the Answers component of OBIEE/OCDA, which does not require any programming skills. You can distinguish between people who can simply create ad hoc reports and those who can save the reports they create to a dashboard so that other people can use them.
LSH Programmers are people who can modify the functionality of OCDA by modifying the predefined ETL Programs that OCDA uses to transform transactional source data in Oracle LSH for use in OCDA. They may also create new ETL Programs to support custom dashboards and reports in OCDA.
LSH Schedulers are people who schedule OCDA jobs, including the data loading job and the user data access jobs. They need privileges similar to LSH Programmers.
LSH Administrators are people who set up Oracle LSH, including Oracle LSH security, and grant privileges to other users.
Setting up security for these user types is described in the following sections and summarized in Table 6-1,Summary of the Oracle LSH Security Setup Example.
Oracle LSH handles user authentication for OCDA through its integration with Oracle Applications UMX. You create and maintain user accounts for OCDA in Oracle LSH. When a user logs in, OBIEE passes the user name and password to Oracle LSH, which verifies that they are a valid combination and populates the OBIEE Group session variable with a list of the user groups the user belongs to.
You can create Oracle LSH user accounts in the following ways:
Create each user account separately through the Oracle Applications UMX user interface. For more information, refer to the Oracle LSH System Administrator's Guide chapter on setting up security.
If you have an Oracle LDAP Directory, migrate users to Oracle Applications. For more information, refer to My Oracle Support (ID 1508321.1).
When you create an Oracle LSH user account, you assign one or more application roles to it. These roles are different from the object security roles you create and assign to user groups and users within groups. For more information, refer to the Oracle LSH System Administrator's Guide chapter on setting up security. Different users need different roles:
OCDA End Users: Give OCDA end users the LSH Consumer role.
LSH Administrators: You must create at least one user with each of these application roles: LSH System Admin role, LSH Adapter Security Admin role, LSH Security Admin role, LSH Function Security Admin role, and LSH Groups Admin role.
LSH Programmers: Give LSH Programmers the LSH Definer application role.
OCDA Programmers: Give OCDA Programmers the LSH Consumer role.
LSH Schedulers: Give LSH Schedulers the LSH Definer application role.
Authorization determines which parts of OCDA's OBIEE user interface, and in some cases which parts of Oracle LSH, users can access. The tasks required to set up user authorization are:
You can do all the Oracle LSH tasks in either of two ways:
through the Oracle LSH user interface. For more information, refer to the Oracle LSH System Administrator's Guide chapter on setting up security.
using Oracle LSH public APIs. For more information, refer to the Oracle LSH Application Developer's Guide chapter on using APIs.
For conceptual information on Oracle LSH security, refer to the Oracle LSH Implementation Guide chapter on designing a security system. For detailed instructions on all Oracle LSH security setup tasks, refer to the Oracle LSH System Administrator's Guide chapter on security. For background information on the integration of OBIEE with Oracle LSH, refer to the OBIEE section in the Business Areas chapter of the Oracle LSH Application Developer's Guide.
All OCDA End Users—people who view Oracle Clinical and Siebel Clinical data in OBIEE—must be associated with one or more OBIEE user groups. The OBIEE groups determine privileges allowed to users and allow access to the shipped OCDA dashboards and reports. To associate users with an OBIEE user group, you assign their Oracle LSH user account to an Oracle LSH user group with the same name as the required OBIEE user group.
OCDA provides a set of predefined OBIEE user groups. You can create additional groups as needed.
Note:
To perform administrative tasks in OBIEE, you must be a member of OBIEE's predefined Administrator group.OCDA includes predefined OBIEE user groups (called groups in OBIEE) to allow OCDA end users access to predefined dashboards. Each dashboard allows access to a predefined set of reports. For more information about predefined reports, refer to Appendix A, Dashboards and Reports.
The predefined user groups allow dashboard access as follows:
OCDA-StudyManager: CO - Document Management, CO - Site and Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
OCDA-CRA: CRA EDC , CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
OCDA-DataEntryManager: CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
OCDA-DataManager: DM EDC, DM Paper, CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
OCDA-ProjectManager: CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
OCDA-Site: CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
The last two user groups are predefined, but if you want to use them you must associate the groups with dashboards.
For more information, refer to Assigning OBIEE User Groups to Dashboards and Reports.
Note:
OCDA ships with both the Presentation catalog and Repository groups for each predefined user group.You can create additional user groups in OBIEE as needed; for example:
If you create new dashboards or reports, you may need new user groups to manage access to them.
To create new dashboards and reports you must allow some users—OCDA Programmers in the example—access to the OBIEE Answers component, for which they need to be in a user group with access to Answers.
For each new user group you need, you must create identically named user groups in three places:
Create a new group in the Presentation catalog: Log in to OBIEE, click Settings > Administration > Manage Presentation Catalog Groups and Users. For more information, refer to the Oracle Business Intelligence Presentation Services Administration Guide.
Create a new group in the OBIEE Repository. If you wish, you can use the group to provide increased security at the RPD level. For more information, refer to the Oracle Business Intelligence Server Administration Guide.
Then in Oracle LSH, navigate to OCDA_domain > OCDA_OBIEE_CODE_APP_AREA > OCDA_OBIEE_WA > OCDA Data Warehouse. Check out the Business Area, upload the revised RPD file as source code, and reinstall the Work Area to deploy the revised RPD file. For more information, refer to the Oracle LSH Application Developer's Guide Business Area chapter's section on OBIEE.
Create a new user group in Oracle LSH. For more information, refer to Creating User Groups in Oracle LSH.
Note:
The OBIEE Presentation catalog and Repository user groups and the corresponding Oracle LSH user group must all have exactly the same name.To use a group to allow users access to particular dashboards or reports, you must assign the new group to one or more dashboards or reports.
Log in to OBIEE, click Settings > Administration > Manage Interactive Dashboards. For more information, refer to the Oracle Business Intelligence Presentation Services Administration Guide.
For users to access any part of OCDA's OBIEE user interface, they must belong to an Oracle LSH user group that has a corresponding OBIEE user group of the same name. The user can access the parts of the user interface specified for the OBIEE user group.
Some users, such as the LSH Definer, Scheduler, and Administrator in the example, need to work in Oracle LSH. For users to perform most tasks in Oracle LSH, they must belong to an Oracle LSH user group.
You must create one Oracle LSH user group with the same name as each OBIEE user group, including each of the predefined OBIEE user groups—OCDA-Site, OCDA-CRA, OCDA-DataEntryManager, OCDA-DataManager, OCDA-ProjectManager—that you want to use.
In addition, you must create Oracle LSH user groups for people who need access to Oracle LSH but not necessarily to OCDA.
Example To support the example user types, create these user groups:
OCDA End User Groups: These correspond to the predefined OBIEE user groups or other OBIEE user groups you create to allow access to dashboards and reports.
OCDA Programmer Group: This group is for people who have access to the Answers component of OBIEE.
LSH Programmer Group: LSH Programmers and LSH Schedulers can belong to the same user group, with different roles to differentiate what they can do. You might want OCDA Programmers to be in the same group so that they can create and modify ETL Programs to support the dashboards and reports they create.
LSH Administrator Group: You do not need this group unless you want to allow LSH Programmers to modify some ETL Programs but not others. For more information, refer to Assigning Roles to Oracle LSH User Groups and Roles for Administrators.
You must create roles in LSH that define which actions a user with that role can take on an object (such as a Program) in Oracle LSH. You then assign roles to user groups. When you assign a user to a group, you must assign them to a role in the group at the same time.
OCDA User Role OCDA End Users must have a role with the following privileges:
View operation on Business Area instances of the Default subtype
Read Data operation on Table instances of the Default subtype
Note:
Do NOT give the role the View operation on Table instances of the Default subtype. If you do, OCDA End Users can use Oracle LSH to see all data in the Table instances to which their user group is assigned, even if you limit their access to particular studies and sites through OCDA.Note:
To give a role operations on an object subtype in Oracle LSH, you work in the Security tab. First define the role in the Roles subtab. Then go to the Subtypes subtab, find the object, then its Default subtype, and then add the role to the appropriate operation. For more information, refer to the Oracle LSH System Administrator's Guide chapter on setting up security.Example To support the basic user types, you can create the following roles for the example user groups:
Each Oracle LSH user group corresponding to an OCDA user group—including groups you create and the predefined OCDA user groups—must have the role described above, which we call the OCDA User Role in the example.
OCDA Programmers need the same Oracle LSH role as OCDA End Users: the OCDA User Role.
You can customize your installation of OCDA. For more information about how to customize the ETL programs, refer to Chapter 5, Extract Transform Load Programs. To support customization, create roles like the following:
Note:
In all cases, assign the role to the operation on the Default subtype of the object type listed. All predefined OCDA objects are created using the Oracle LSH Default subtype.ETL Modifier is for people who need to modify the shipped Informatica ETL Programs in Oracle LSH. This role requires the View operation on Domains; the View and Modify operations on Application Areas, Execution Setups, Programs, Program instances, Parameters, and Work Areas; and the Install operation on Work Areas.
In order to modify the data structures, the role also requires the View and Modify operations on Tables and Table instances and the Create Tables and Create Variables operations on Application Areas.
ETL Creator is for people who need to create new Load Sets and Informatica ETL Programs in Oracle LSH in order to load additional data from Oracle Clinical and Siebel Clinical and transform it to the start schema format. This role requires the View operation on Domains; the View and Modify operations on Application Areas, Execution Setups, Load Sets, Load Set instances, Programs, Program instances, Parameters, Tables, Table instances and Work Areas; the Install operation on Work Areas, and the Create Program, Create Table, and Create Variable operations operation on Application Areas.
RPD Modifier is for people who need to modify the Repository and the corresponding RPD file in the OCDA Business Area in Oracle LSH. This role requires the View operation on Domains; the View and Modify operations on Application Areas, Business Areas, Business Area instances, Execution Setups, and Work Areas; and the Install operation on Work Areas.
In order to modify the data structures, the role also requires the View and Modify operations on Tables and Table instances and the Create Tables and Create Variables operations on Application Areas.
ETL Scheduler. At least one user needs to be able to schedule execution of the program that refreshes Oracle Clinical and Siebel Clinical data in the OCDA data warehouse. This role requires the View operation on Domains and Application Areas; the Submit operation on Execution Setups, and the View operation on Program instances and Work Areas.
In addition, programmers who need to create or modify ETL programs need privileges on the Informatica Adapter, and programmers who need to modify the RPD need privileges on the OBIEE adapter. For more information about the operations required, refer to the Oracle LSH System Administrator's Guide chapter on adapters, section on adapter security.
Most administrator application roles do not need any object-security roles; that is, roles that grant privileges to perform operations on object subtypes. However, if you decide to specify which ETL Programs LSH Programmers can modify, create the LSH Security Administrator role with the Apply Security operation on all container and primary object types, Default subtype.
Assign the roles you have created to the appropriate Oracle LSH user group.
Note:
Every Oracle LSH user group is automatically assigned a role called Group Administrator. Only a user with this role in a group can add other users to the group and assign roles to them. Each Oracle LSH user group must have at least one group administrator. This user must have the LSH Groups Admin application role.Example To support the basic user types, you can add roles to user groups as follows:
OCDA End User Groups: These correspond to the predefined OBIEE user groups or other OBIEE user groups you create to allow access to dashboards and reports. Assign the OCDA User Role to each of these groups.
OCDA Programmer Group: Assign the OCDA User Role to this group.
LSH Programmer Group: Assign the roles ETL Modifier, ETL Creator, RPD Modifier, and ETL Scheduler to this group.
LSH Administrator Group: Assign the role LSH Security Administrator to this group.
OCDA users cannot do anything in either OBIEE or Oracle LSH if they do not belong to a user group that is assigned to an Oracle LSH object. You can handle this in different ways:
A user with the LSH Security Bootstrap Admin application role can assign all user groups to the OCDA_domain. All the predefined OCDA Programs, Tables, and other objects automatically inherit the user group assignments. The roles you define limit what users in the user groups can do.
A user with the LSH Security Admin application role can assign selected user groups to selected objects. This has little advantage for controlling the activities of OCDA End Users, but does enable you to allow LSH Programmers to only certain ETL Programs, or to a new Application Area for the purpose of creating new ETL Programs without allowing access to the predefined ETL Programs.
You must assign at least one user to the Group Administrator role in each group. Each group administrator then assigns users to the group with an appropriate role. Users can belong to more than one user group.
The following table summarizes the information in the preceding sections. In addition to the setup displayed in Table 6-1, the user groups must be assigned to Oracle LSH objects. For more information, refer to Assigning Oracle LSH User Groups to Objects.
Table 6-1 Summary of the Oracle LSH Security Setup Example
| Example User | LSH Application Role | Example LSH User Group | Example Object Security Role |
|---|---|---|---|
|
OCDA End User |
LSH Consumer |
One of the following: OCDA-StudyManager OCDA-Site OCDA-CRA OCDA-DataEntryManager OCDA-ProjectManager OCDA-DataManager |
OCDA User Role |
|
OCDA Programmer |
LSH Consumer |
OCDA Programmer Group |
OCDA User Role* |
|
LSH Programmer |
LSH Definer |
LSH Programmer User Group |
One or more of the following: ETL Modifier ETL Creator RPD Modifier* |
|
ETL Scheduler |
LSH Definer |
LSH Programmer User Group |
ETL Scheduler |
|
LSH Administrator |
Each of the following roles must be assigned to at least one user: LSH System Admin LSH Adapter Security Admin LSH Security Admin LSH Groups Admin LSH Security Bootstrap Admin |
Each user group must have an LSH Group Administrator. The LSH Security Admin belongs to the LSH Administrator user group (optional). Other Admin users do not need to be assigned to a user group. |
LSH Administrator |
*Note:
You may want the same person to have both the OCDA User Role in the OCDA Programmer user group and the RPD Modifier role in the LSH Programmer user group.This section contains the following topics:
You can set two variables to either allow all users access to data from all studies and study sites or you can require each user to have explicit access to particular studies and study sites. For more information, refer to Setting the Systemwide Access Variables.
In OCDA:
Study data means data pertaining to the study as a whole, including planned sites, planned enrollment, and the ratio of actual to planned subjects. It is not a roll-up of all patient data from all study sites. For security purposes, all documents are considered Study data as well, regardless of whether the document pertains to a Study, a Region, or a Study-Site.
Study site data means all other OCDA data, including information about discrepancy management, CRF verification and approval, workloads, and more.
This means that if you set the variables to require explicit access:
If users needs access to study-wide data on planned sites, enrollment, or documents, they must have explicit access to study data for that study. Having access to all study sites does not automatically allow access to study data.
If users needs access to study site data from every site in a study, they must have explicit access to each study site. You can set up this access automatically by importing user privileges from Oracle Clinical or Siebel Clinical. For more information, refer to Importing Study and Study Site Data Access Privileges.
Note:
If a user has access to multiple, but not all, sites in a study, the totals displayed in OCDA reports reflect the totals for the sites to which the user has access, not the totals for all sites in the study. For more information, refer to Study-Site Access Example.The following static repository variables determine whether explicit access to study or study site data is required for all users:
Enable_Study_Access_Sec: If set to Y, all users must have explicit access granted to study-level data for a particular study in order to see that data. If set to N, all users can see study-level data for all studies.
Enable_Study_Site_Access_Sec: If set to Y, all users must have explicit access to a particular study site in order to see site-level data for that study site. If set to N, all users can see site-level data for all study sites.
The default value for both variables is N.
Note:
If you set these variables to Y you must populate a set of tables with user access data. For more information, refer to Importing Study and Study Site Data Access Privileges.Oracle recommends that you set both variables to the same value.
To change the value for either variable:
Stop the BI Server and the BI Presentation Server Services.
In Oracle LSH, navigate to OCDA_domain > OCDA_OBIEE_CODE_APP_AREA > OCDA_OBIEE_WA > OCDA Data Warehouse, and check out the Business Area.
Using the OBIEE Administrator tool, edit the Repository:
On the Manage Menu, choose Variables.
In the Variable Manager dialog, choose Repository, then Variables, then Static.
Open the properties of the variable, either by double-clicking it or through the context menu.
Edit the value of Default Initializer for the variable: Y enables access control; N disables access control.
Exit the Static Repository Variable dialog.
Exit the Variable Manager.
Save the modified Repository.
Upload the new RPD file as the Business Area's Source Code.
For more information, refer to the Oracle LSH Application Developer's Guide chapter on Business Areas for instructions.
Check in the Business Area.
Install Work Area OCDA_OBIEE_WA.
For more information, refer to the Oracle LSH Application Developer's Guide for instructions.
Start the BI Server and BI Presentation Server Services.
OCDA uses three database tables to control users' access to rows of data in the star schema fact tables that pertain to particular studies and study sites. The data access tables are:
W_HS_APPLICATION_USER_D contains a list of the user accounts that can have data access granted to particular studies and study sites. It must be populated from an external source. OCDA includes a sample ETL Program for this purpose. For more information, refer to Importing Study and Study Site Data Access Privileges.
W_HS_STUDY_ACCESS_SEC controls which users can see study-level data on which studies.
W_HS_STUDY_SITE_ACCESS_SEC controls which users can see study site-level data on which study sites.
The data access tables must be populated with data. OCDA includes a set of template ETL programs for this purpose. The programs are called template programs because you will need to adjust them according to your particular configuration, if you are enabling access control. If you are not enabling access control, the template programs can be used as they are. The following list enumerates the degrees to which you may want to modify the template programs:
If you set the systemwide access variables to N, run the template ETL programs as is to populate the tables with a dummy user. All users have access to all study-level and study site-level data for all studies and sites.
If you set the systemwide access variables to Y, modify the ETL programs as necessary to import user access information from Oracle Clinical and Siebel Clinical. If there are people who should be able to use OCDA but do not currently have either Oracle Clinical or Siebel Clinical user accounts with privileges for specific studies or sites set, you must up create user accounts with the desired privileges in one of the source transactional systems.
If you set the systemwide access variables to Y, modify the ETL programs as necessary to import user access information from some other source.
About Oracle Clinical Template Programs
The template ETL programs for Oracle Clinical are:
OCDA_INFA_Application_User_D_SDE_OC_PRG
OCDA_INFA_Study_Access_Sec_SDE_OC_PRG
OCDA_INFA_Study_Site_Access_Sec_SDE_OC_PRG
The Oracle Clinical table OPA.OPA_LEVEL_PRIVS stores study and study site data access information for Oracle Clinical and Oracle Clinical Remote Data Capture (RDC) Onsite users. The Oracle Clinical or RDC administrator sets these privileges in the Maintain Access to Studies and Maintain Access to Sites windows in either Oracle Clinical or the RDC Administration application.
The template OC ETL programs read data from this table and populate the data access tables in the OCDA warehouse in Oracle LSH.
OCDA uses this data to allow users access to study and study site data in OBIEE. In Oracle Clinical and RDC the concept of study and study site data access is different from OCDA's, and you can specify a variety of privileges on studies and study sites, which is not required in OCDA where all data access is view-only. The template OCDA ETL programs interpret the Oracle Clinical/RDC data as follows:
If a user has been granted any privileges on a study site in OPA_LEVEL_PRIVS, the programs give the user study site-level access to that study site in OCDA.
If a user has been given any privileges on a study in OPA_LEVEL_PRIVS, the programs give the user:
Study-level access to that study in OCDA
Study site-level access to all the study sites in that study
The template ETL programs also remove the Oracle Clinical OPS$ prefix from each user name. You will likely need to alter this translation of Oracle Clinical user name to OCDA user name. For more information, refer to Modifying the Data Access Programs.
About Siebel Clinical Security ETL Programs
The secuirty ETL programs for Siebel Clinical are:
OCDA_INFA_Application_User_D_SDE_SC_PRG
OCDA_INFA_Study_Access_Sec_SDE_SC_PRG
OCDA_INFA_Study_Site_Access_Sec_SDE_SC_PRG
OCDA_S_PARTY_LS
OCDA_INFA_Party_Parent_SDE_SC_PRG
OCDA_PLS_SC_PARTY_HIERARCHY_PRG
OCDA_INFA_Study_Hierarchy_SDE_SC_PRG
OCDA_INFA_Study_Site_Hierarchy_SDE_SC_PRG
These programs read from the standard tables describing Siebel Clinical users and protocols, and the access that users have to studies. Review the programs, and adjust them to correspond to any changes you have made from the standard Siebel Clinical model.
The other security ETL programs are:
OCDA_INFA_Application_User_D_SDE_Pool_PRG
CDA_INFA_Study_Access_Sec_SDE_Pool_PRG
OCDA_INFA_Study_Site_Access_Sec_SDE_Pool_PRG
OCDA_INFA_Application_User_D_SIL_PRG
CDA_INFA_Study_Access_Sec_SIL_PRG
OCDA_INFA_Study_Site_Access_Sec_SIL_PRG
You may need to modify the data access ETL programs for the following reasons:
User Name Conversion Modification You may need to edit the SDE programs to adapt the user name conversion to your input Oracle Clinical or Siebel Clinical user names and your output OCDA user names. Be careful; if the following conditions are not met, names will not match up and access control will fail.
The conversion performed in the all three SDE programs must be identical
The resultant user name must be the same as the Oracle LSH user name used for OCDA purposes. SDE ETL programs that execute the ETL to populate the data access tables have a parameter for entering the email portion of the standard Oracle LSH user name format.
Interpretation Logic Modification You may prefer to interpret the Oracle Clinical or Siebel Clinical privileges differently in OCDA.
Source Modification You may want to import data access information from another source.
For instructions on modifying ETL programs, refer to Customizing an ETL Program.
You should run your versions of these programs:
when you first set up OCDA
when new users need access
when new studies are added
when new sites are added to studies
when the systemwide access variable settings are modified
You must run the programs in the order in which they are listed in Importing Study and Study Site Data Access Privileges. For more information, refer to Scheduling an ETL Program.
In Study 012345, users U2 and U3 have study-site access defined in the OCDA data access table W_STUDY_ACCESS_STUDY_SITE_SEC as follows (note that user U1 is not in the table at all):
| APPLICATION_USER_WID | STUDY_WID | STUDY_SITE_WID |
|---|---|---|
| U2 | A | A1 |
| U2 | A | A2 |
| U3 | B | B1 |
| U3 | B | B2 |
The distribution of discrepancies by study site, as stored in the discrepancies aggregate table in the warehouse, is:
| Study | Study Site | Number Of Discrepancies |
|---|---|---|
| A | A1 | 20 |
| A | A2 | 15 |
| B | B1 | 30 |
| B | B2 | 10 |
| B | B3 | 20 |
A query on this data has been created and saved as a report:
Users U1, U2, and U3 can run the report. When user U1 runs the report, nothing can be seen. U1 has no access to any study site data.
When user U2 runs the report, U2 sees the following:
| Study | Number of Discrepancies |
|---|---|
| A | 35 |
And U2 drills down within Study A, the following can be seen:
| Study | Site | Number of Discrepancies |
|---|---|---|
| A | A1 | 20 |
| A | A2 | 15 |
| Total | 35 |
When user U3 runs the report, U3 sees the following:
| Study | Number of Discrepancies |
|---|---|
| B | 40 |
That is, U3 sees the sum of the values for the sites U3 is entitled to see, not the sum for the study. For user U3, it is as if site B3 does not exist. Drilling down shows the same effect:
| Study | Site | Number of Discrepancies |
|---|---|---|
| B | B1 | 30 |
| B | B2 | 10 |
| Total | 40 |
Note:
A given document can pertain to study-site, a region, or a study. Ideally, there would be separate security controls for each level. However, in OCDA Release 2.0, we are applying the same security to all documents. As every region and study-site belongs to a study, we control documents at the study level.
|
 Copyright © 2009, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
