| Oracle® Clinical Development Analytics User and Administrator Guide Release 2.0.0.3 for Standard Configuration Part Number E22699-01 |
|
|
View PDF |
| Oracle® Clinical Development Analytics User and Administrator Guide Release 2.0.0.3 for Standard Configuration Part Number E22699-01 |
|
|
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, and Informatica ETL Execution Plans and transform Oracle Clinical and Siebel Clinical data structures into the star schemas required by Oracle Business Intelligence Enterprise Edition (OBIEE), which reads from the star schemas and provides the user interface where end users can view and analyze data through dashboards and reports.
OCDA security includes:
Authentication. OCDA user accounts are maintained in OBIEE RPD.
Authorization. You assign user accounts to user groups in OBIEE RPD. On login, OBIEE ascertains the authenticated user's user group, 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 can create additional user groups as needed in OBIEE.
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.
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.
INFA 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 Infa repository for use in OCDA. They may also create new ETL Programs to support custom dashboards and reports in OCDA.
OCDA Schedulers are people who schedule OCDA jobs, including the data loading job and the user data access jobs. They need privileges similar to INFA Programmers.
DAC/INFA Administrators are people who set up DAC, including Informatica Setups, and grant privileges to other users.
DAC handles creation and maintenance of users for ETL administration of OCDA. OBIEE handles reports related user authentication for OCDA .
You can create user accounts in the following ways:
Create users in DAC. For more information, refer to the Oracle® Business Intelligence Data Warehouse Administration Console Guide.
If you have an Oracle LDAP Directory, migrate users to Oracle Applications. For more information, refer to My Oracle Support (ID 1508321.1).
When a user logs in, OBIEE verifies that they have valid credentials and populates the OBIEE Group session variable with a list of the user groups the user belongs to.
Authorization at the OBIEE level determines which parts of OCDA's OBIEE user interface, users can access. The tasks required to set up user authorization are:
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 OBIEE account to an 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.
Note:
The OBIEE Presentation catalog and Repository user groups 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.
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.
DAC/INFA Administrator Group: You do not need this group unless you want to allow INFA Programmers to modify some ETL Programs but not others.
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.
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.
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:
SDE_OC_Application_User_D
SDE_OC_Study_Access_Sec
SDE_OC_Study_Site_Access_Sec
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 .
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:
SDE_SC_Application_User_D
SDE_SC_Study_Access_Sec
SDE_SC_Study_Site_Access_Sec
SDE_SC_Party_Parent
OCDA_SC_PARTY_HIERARCHY
SDE_SC_Study_Hierarchy
SDE_SC_Study_Site_Hierarchy
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:
SIL_Application_User_D
SIL_Study_Access_Sec
SIL_Study_Site_Access_Sec
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 the SDE programs must be identical
The resultant user name must be the same as the 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 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 Execution Plan.
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 Execution Plan.
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.0.3, 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 © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
