| Oracle® Health Sciences Clinical Development Analytics Administrator's Guide Release 2.1 for Plus Configuration E28551-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Health Sciences Clinical Development Analytics Administrator's Guide Release 2.1 for Plus Configuration E28551-01 |
|
|
PDF · Mobi · ePub |
This chapter contains the following topics:
Defining security for CDA includes the following tasks
CDA Authorization. In this, you define each CDA user, and determine which OBIEE activities the user is entitled to perform. CDA delegates authentication of its OBIEE user accounts to LSH, so you must define CDA users in LSH.
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 CDA the user can use. Predefined OBIEE user groups determine the privileges allowed to users and allow access to the shipped CDA 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 Specification. In this, you determine the study-sites and studies for which each CDA user is permitted to see data. For more information, refer to Setting Up Study and Study Site Data Access for Users.
ETL Use Authorization. In this, you determine which users shall have the ability to view, modify, and execute ETL for CDA. This has two parts, one of which is needed only if you are implementing Multi-source Integration.
Direct-path ETL is executed through LSH. To use CDA, you must define at least one LSH account with privileges to execute ETL. You may want to enable one or more LSH accounts to modify direct path ETL as well. Security for direct path ETL is controlled through LSH. For information on Direct-path ETL authorization, refer to Roles for LSH Programmers.
Deduplication ETL is used only for Multi-source Integration. It is responsible for extracting modified source data for dimension records, and invoking the deduplication engine to identify duplicates in the dimension data. This ETL is executed through DAC, rather than through LSH. To define and authorize DAC and Informatica users for these purposes, consult the respective product documentation.
Figure 2-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.
CDA End Users are people who can view Oracle Clinical and Siebel Clinical data in CDA through dashboards and reports. The specific dashboards and reports they can view is determined by the user groups they belong to.
CDA Programmers are people who are authorized to create their own reports in the Answers component of OBIEE/CDA, 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 CDA by modifying the predefined ETL Programs that CDA uses to transform transactional source data in Oracle LSH for use in CDA. They may also create new ETL Programs to support custom dashboards and reports in CDA.
LSH Schedulers are people who schedule CDA 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 2-1,Summary of the Oracle LSH Security Setup Example.
Oracle LSH handles user authentication for CDA through its integration with Oracle Applications UMX. You create and maintain user accounts for CDA 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:
CDA End Users: Give CDA 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.
CDA Programmers: Give CDA Programmers the LSH Consumer role.
LSH Schedulers: Give LSH Schedulers the LSH Definer application role.
Authorization determines which parts of CDA'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 perform 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 CDA 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 CDA 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.
CDA 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.CDA includes predefined OBIEE user groups (called groups in OBIEE) to allow CDA end users access to predefined dashboards. Each dashboard allows access to a predefined set of reports.
The predefined user groups allow dashboard access as follows:
CDA-StudyManager: CO - Document Management, CO - Site and Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
CDA-CRA: CRA EDC , CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
CDA-DataEntryManager: CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
CDA-DataManager: DM EDC, DM Paper, CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
CDA-ProjectManager: CO - Document Management, CO - Site Recruitment Overview, CO - Study and Region Overview, and CO - Subject Retention
CDA-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:
CDA 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—CDA 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 CDA'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—CDA-Site, CDA-CRA, CDA-DataEntryManager, CDA-DataManager, CDA-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 CDA.
Example To support the example user types, create these user groups:
CDA 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.
CDA 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 CDA 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.
CDA User Role CDA 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, CDA 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 CDA.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 CDA user group—including groups you create and the predefined CDA user groups—must have the role described above, which we call the CDA User Role in the example.
CDA Programmers need the same Oracle LSH role as CDA End Users: the CDA User Role.
You can customize your installation of CDA. For more information about how to customize the ETL programs, refer to Chapter 3, 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 CDA 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 CDA 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 CDA 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:
CDA 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 CDA User Role to each of these groups.
CDA Programmer Group: Assign the CDA 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.
CDA 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 CDA 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 CDA 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 2-1, the user groups must be assigned to Oracle LSH objects. For more information, refer to Assigning Oracle LSH User Groups to Objects.
Table 2-1 Summary of the Oracle LSH Security Setup Example
| Example User | LSH Application Role | Example LSH User Group | Example Object Security Role |
|---|---|---|---|
|
CDA End User |
LSH Consumer |
One of the following: CDA-StudyManager CDA-Site CDA-CRA CDA-DataEntryManager CDA-ProjectManager CDA-DataManager |
CDA User Role |
|
CDA Programmer |
LSH Consumer |
CDA Programmer Group |
CDA 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 CDA User Role in the CDA 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 CDA:
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 CDA 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 need 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 need 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 CDA 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.
CDA 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. CDA 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. CDA 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 CDA 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 CDA warehouse in Oracle LSH.
CDA 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 CDA's, and you can specify a variety of privileges on studies and study sites, which is not required in CDA where all data access is view-only. The template CDA 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 CDA.
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 CDA
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 CDA user name. For more information, refer to Modifying the Data Access Programs.
About Siebel Clinical Security ETL Programs
The security ETL programs for Siebel Clinical are:
OCDA_INFA_Application_User_D_SDE_SC_PRG
OCDA_INFA_Study_Site_Dim_SDE_SC_PRG
OCDA_INFA_Study_Access_Sec_SDE_SC_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_PLS_Application_User_D_SDE_Pool_PRG
OCDA_PLS_Study_Access_Sec_SDE_Pool_PRG
OCDA_PLS_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 CDA 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 CDA 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 CDA.
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 CDA
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 CDA 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 CDA 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 © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
