Oracle® Clinical Remote Data Capture Onsite

Administrator's Guide

Release 5.2

E86391-01

August 2017

Oracle Clinical Remote Data Capture Onsite Administrator's Guide, Release 5.2

E86391-01

Copyright © 1996, 2017, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

List of Examples

List of Figures

List of Tables

Preface

- Audience

- Documentation Accessibility

- Finding Information and Patches on My Oracle Support

- Finding Oracle Clinical Documentation

- Conventions

1 Getting Started with Administration Tasks

- 1.1 About Administrator Privileges for Maintaining RDC

- 1.1.1 About Database Roles for RDC Users

- 1.1.2 About User Roles with Limited Administrator Privileges

- 1.2 Starting the RDC Administration Application

- 1.2.1 RDC Administration Main Window

- 1.2.2 About Maintain Mode versus Query Mode

- 1.3 Starting the Oracle Clinical Application

- 1.4 Setting Web Command Access

- 1.5 Stop the WebLogic Admin Server

2 Securing Remote Data Capture

- 2.1 About Security Privileges

- 2.1.1 Minimum Requirement for Privileges

- 2.1.2 Privileges and Batch-Loaded CRFs

- 2.1.3 Site Privileges Take Precedence Over Study Privileges

- 2.2 Assigning Study and Site Security Privileges

- 2.2.1 Opening the Security Privileges Forms

- 2.2.2 Configuring Study and Site Security Privileges

- 2.2.3 Granting Administrator Privileges to Individual Users

- 2.3 Granting Oracle Clinical Users Access to RDC

- 2.4 Managing Security with Data Entry Configuration Settings

- 2.4.1 Changing the Data Entry Configuration Settings

- 2.4.2 Authority to Resolve Discrepancies upon Discrepancy Creation

- 2.4.3 Authority to Update Locked CRFs and Override Repeating Defaults

- 2.4.4 Modifying Data Entry Configurations at the Database, Study, and User Levels

- 2.4.4.1 At the Local Database Level

- 2.4.4.2 At the Study Level or the User Level

- 2.5 Restricting Actions Against Locked CRFs

- 2.6 Restricting Access to Data Collection Instruments (DCIs)

- 2.6.1 Changing the Default Access to DCIs

- 2.6.2 Defining DCI Access within a Study

- 2.6.2.1 Opening the Maintain Access to DCIs within Study Form

- 2.6.2.2 Defining Inclusions and Exclusions for DCI Access

3 Customizing with RDC Configurations

- 3.1 About the RDC Configurations

- 3.1.1 Default Configurations

- 3.1.2 Assignment Parameters

- 3.1.2.1 Default Value (%) for Assignment Parameters

- 3.1.2.2 Assigning Configurations

- 3.1.2.3 Precedence and Parsing of Assignment Parameters

- 3.2 Managing RDC Configurations

- 3.2.1 Opening and Using the RDC Configurations Form

- 3.2.2 Creating a New Configuration

- 3.2.3 Specifying the Settings for a Configuration

- 3.2.4 Assigning Configurations to Users

- 3.2.4.1 Modifying the Existing Assignments for a Configuration

- 3.2.4.2 Creating New Assignments for an Existing Configuration

- 3.2.5 Deleting Assignments and Configurations

- 3.2.6 RDC Configurations in the Oracle Clinical Reference Local Codelists

- 3.3 Configuration Settings for RDC

- 3.3.1 Customizing the Label for the Links Section on the Home Page

- 3.3.2 Hiding the Preferences Links

- 3.3.3 Displaying Time Stamps in Local Time

- 3.3.4 Allowing CRF Group Actions

- 3.3.5 Using the Oracle Clinical Accessibility Rules

- 3.3.6 Disabling the Save Complete Prompt

- 3.3.7 Specifying a Default Highlighting Scheme for the Data Entry Window

- 3.3.8 Allowing Access to CRFs Entered via Oracle Clinical

- 3.3.9 Suppressing the Validation Error Alert

- 3.4 Required Parameters in an rdcConfig.properties File

4 Configuring Discrepancy Management

- 4.1 Tools for Configuring Discrepancy Management

- 4.2 Defining the Reasons for Discrepancies

- 4.2.1 Defining the Reasons for Manual Discrepancies

- 4.2.2 Defining the Reasons for Univariate Discrepancies

- 4.2.3 Defining the Reasons for Multivariate Discrepancies

- 4.3 Defining the Review Statuses for Discrepancies

- 4.3.1 Default Entries for the DISCREPANCY REV STATUS CODE Codelist

- 4.3.2 Rules for the DISCREPANCY REV STATUS CODE Codelist

- 4.4 Configuring the Access Statuses for Discrepancies

- 4.4.1 Access Status Values

- 4.4.2 Colors Used to Indicate Discrepancy Access Status

- 4.4.3 Default Entries for the DISCREPANCY STATUS role Codelists

- 4.4.4 Rules for the DISCREPANCY STATUS role Codelist

- 4.5 Configuring the Actions Allowed against Discrepancies

- 4.5.1 Default Entries for the DISCREPANCY ACTIONS role Codelists

- 4.5.2 Rules for the DISCREPANCY ACTIONS role Codelist

- 4.6 Defining the Resolution Reasons for Discrepancies

- 4.7 Preventing Update to OTHER Discrepancies

5 Configuring Custom Review Types

- 5.1 Review Statuses for Custom Review Types

- 5.2 Define Custom Review Type Requirements

- 5.2.1 Set Custom Review Requirement for the Installation

- 5.2.2 Set the Custom CRF Review Requirement for a Study

- 5.2.3 Set Custom Review Requirement for a GLIB DCI

- 5.2.4 Set Custom Review Requirement for a Study DCI

- 5.3 Finding CRFs with the Review Not Required (RN) Status Set by Users

- 5.4 Viewing Audit History for Changes in Custom Review Requirements

- 5.5 Add Custom Review Types

- 5.5.1 Deactivate Custom Review Types

- 5.6 Assign Custom Review Type Privileges to Users

- 5.7 Define Custom Review Type Activities

6 Customizing Data Entry Behavior

- 6.1 Configuring the DCI Form Runtime Settings

- 6.1.1 Defining the DCI Form Runtime Settings at the Database Level

- 6.1.2 Defining Report Settings at the Study Level

- 6.1.3 Enabling HTML Data Entry for RDC

- 6.1.4 Displaying the Visit-Owning Interval on the Casebooks Page

- 6.1.5 Allowing Investigator Comments

- 6.1.6 Adding a Customized Reference Field to the Search Pane

- 6.1.6.1 Searching and Viewing Enhancements for the Customized Field

- 6.1.6.2 Labeling and Enabling Your Customized Search Field

- 6.1.6.3 Writing the Derivation Procedure to Use Your Customized Field

- 6.1.7 Controlling the Display of Conditional Blocks within a CRF

- 6.1.8 Suppressing Prompts and Warnings

- 6.1.8.1 Suppressing the Change Reason Prompt for New Responses

- 6.1.8.2 Suppressing the Change Reason Prompt for Investigator Comments

- 6.1.8.3 Suppressing the Warning for Non-migrated CRFs

- 6.2 Using DCI Book Assignment

- 6.2.1 Manually Assigning Patients to DCI Books Using Oracle Clinical

- 6.2.2 Automatically Assigning the DCI Book upon Initial Data Entry

- 6.2.3 Allowing Patient Book Assignments to Change

- 6.3 Specifying CRFs for Single Use

- 6.4 Customizing the Display of a List of Values

- 6.5 Defining the List of Allowable Change Reasons

- 6.5.1 Accessing the Codelists to Customize the Change Reason Values

- 6.5.1.1 Reserved Change Reason Values

- 6.5.1.2 Identifying the Default Change Reason

- 6.5.1.3 Identifying Change Reasons NOT for Use in RDC

- 6.5.2 Making a Reason for Change Optional for Updates to RDCI Comments in Accessible Documents

- 6.6 Setting the Format of Dates

- 6.6.1 Setting Date Formats at the Database Level

- 6.6.2 Setting Date Formats for Individual Users

7 Customizing RDC on the Application Server

- 7.1 Modifying Files on the Application Server

- 7.2 Creating a Launch Page, Button, or Link for RDC

- 7.2.1 Creating or Customizing a Launch Page to Use Provided Scripts

- 7.2.1.1 Sample Java Script for Launching in a New Window without Tool or Menu Bar

- 7.2.1.2 Sample JavaScript for Checking if Compatibility View Is On

- 7.2.2 Customizing the Remote Data Capture URL

- 7.2.3 Adding Custom Text to the RDC Onsite Login Page

- 7.3 Customizing the Reset Password Link

- 7.3.1 Requirements for Using the RDC Onsite Reset Password Utility

- 7.3.2 Resetting versus Changing Passwords

- 7.3.3 Configuring the Reset Password Link

- 7.4 Customizing Branding Images in RDC

- 7.5 Customizing the Contact Us Link

- 7.6 Customizing the Change Password Link

- 7.6.1 Changing the URL and the Name for the Change Password Link

- 7.6.2 Enforcing Profile Limits for the Change Password Page

- 7.7 Customizing the Electronic Signature (Approval) Warning Message

- 7.7.1 Customizing the Approval Warning Messages for the Data Entry Window

- 7.7.2 Customizing the Approval Warning Messages for the Application Pages

- 7.7.3 Other Options for Customizing Approvals

- 7.8 Customizing the Logout Message

- 7.9 Setting the User Session Timeout Value

- 7.9.1 Recommendations for Setting the Session Timeout Value

- 7.9.2 Changing the Session Timeout Value

- 7.10 Setting the Maximum Number of Rows Fetched

- 7.11 Storing Custom Web Pages

- 7.12 Storing the DCIF Images

- 7.13 Customizing the Single View of the Patient Casebooks Page

- 7.13.1 Activating One-Click Navigation to the Single View of Patient Casebooks Page

- 7.13.2 Deactivating the Single View for the Patient Casebooks Page

- 7.14 Hiding Unplanned Visit Buttons in RDC Onsite

8 Working with the RDC Client Package

- 8.1 Deriving Company-Specific Document Numbers

- 8.2 Configuring a Timer Period for Subsequent Electronic Signatures

- 8.3 Configuring the DCI Bookmark Label for the Patient Data Report

- 8.4 Configuring the DCM Bookmark Label for the Patient Data Report

- 8.5 Configuring the Visit Bookmark Label for the Patient Data Report

9 Configuring News

- 9.1 About the News Section in RDC

- 9.2 Creating User Roles that Can Define News Items Only

- 9.3 Creating and Modifying News Items

- 9.3.1 Accessing the Form for Defining News Items

- 9.3.2 Priority and Sequence of News Items

- 9.3.3 Substitution Parameters for News Items

- 9.4 Querying News Definitions

10 Customizing Activities

- 10.1 Displaying the Activities List

- 10.2 Default Activities for RDC

- 10.3 Key Concepts for Activities

- 10.3.1 User Roles and Activities

- 10.3.2 Types of Activities

- 10.3.3 Scope of Activities

- 10.4 Activities Database Tables

- 10.4.1 RDC_ACTIVITIES Database Table

- 10.4.2 RDC_ACTIVITY_TAGS Database Table

- 10.5 Activity Tags and Functions Included with Oracle Clinical

- 10.6 Creating and Maintaining Customized Activities

- 10.6.1 Working with the RDC_ACTIVITIES Table

- 10.6.1.1 Copying Activities

- 10.6.1.2 Deleting Activities

- 10.6.2 Creating an Activity Procedure

- 10.6.3 Adding Counts to Existing Activities

- 10.7 Creating an Activity Tag Function

11 Configuring Links

- 11.1 About Custom Links

- 11.1.1 Links on the Home Page

- 11.1.2 Links on the Patient Summary Report

- 11.1.3 A Link for CRF Help

- 11.2 Using the Maintain Links Form

- 11.2.1 Ordering the Display of Links

- 11.2.2 Defining the Link Text

- 11.2.3 Specifying the URL or Function

- 11.2.4 Specifying the Type of Link

- 11.2.5 Specifying the Link Scope

- 11.2.6 Enabling Patient Summary and CRF Help Links

- 11.3 Link Parameters

- 11.3.1 Parameters for Static Links Based on Scope

- 11.3.2 Parameters for Dynamic Links Based on Scope

- 11.3.2.1 Sample Function Available

- 11.3.2.2 Function Specification for Dynamic Links

- 11.4 Creating Links for the Home Page

- 11.4.1 Defining a Link for the Home Page

- 11.4.2 Parameters for Links with a Scope of None

- 11.4.3 Parameters for Links with a Scope of User

- 11.4.4 Parameters for Links with a Scope of Study

- 11.4.5 Parameters for Links with a Scope of Site

- 11.4.6 Customizing the Label for the Links Section

- 11.5 Defining Links for the Patient Summary Reports

- 11.5.1 Parameters for a Patient Link

- 11.6 Defining a Link for CRF Help

- 11.6.1 Parameters for a CRF Help Link

- 11.7 Querying Link Definitions

- 11.8 About Storing Your Customized Web Pages

12 Customizing Online Help

- 12.1 Defining Help for the Fields in a CRF

- 12.2 Customizing Online Help

- 12.2.1 Copying the RDC Help Files

- 12.2.2 Identifying Individual Topic Files

- 12.2.3 Modifying the Topic Text

- 12.2.4 Diverting the Help Call to a Custom Location

- 12.3 Defining Help for CRFs

13 Configuring Settings for Reports

- 13.1 Defining Settings for the Patient Data Report

- 13.1.1 Defining the Configuration Settings for the Patient Data Report

- 13.1.1.1 Defining Report Settings at the Database Level

- 13.1.1.2 Defining Report Settings at the Study Level

- 13.1.2 About the Patient Data Report Settings

- 13.2 About the File Name for the Deleted CRFs Report

- 13.3 Customizing Bookmark Labels

- 13.4 Printing Left Default Prompts for Repeating Response Fields

14 Generating Reports from the Command Line

- 14.1 Configuring Desktop PDR for Report Generation

- 14.1.1 Contents of the desktoppdr Folder

- 14.1.2 Installing the Java Runtime Environment

- 14.1.3 Copying the Files in the desktoppdr Folder

- 14.1.4 Copying and Modifying the xdo.cfg File

- 14.1.5 Embedding Fonts into the Patient Data Report

- 14.1.5.1 Copying and Configuring the xdobookbinder.cfg File for Fully Embedding Fonts

- 14.1.6 Modifying the RunPDR.cmd File

- 14.1.7 Modifying the RunBlankCasebook.cmd File

- 14.1.8 Adjusting the Heap Size for the Java Virtual Machine (JVM)

- 14.1.8.1 Adjusting JVM Heap Size Options for the Desktop

- 14.1.8.2 Adjusting JVM Heap Size Options on the Reports Server

- 14.2 Generating a Patient Data Report from the Command Line

- 14.2.1 Displaying the Command Syntax

- 14.2.2 Parameters for the RunPDR Command

- 14.3 Generating a Blank Casebook Report from the Command Line

- 14.3.1 Displaying the Syntax for the RunBlankCasebook Command

- 14.3.2 Parameters for the RunBlankCasebook Command

- 14.4 File Names for Reports

15 Collecting Debug Data

- 15.1 Displaying Document Numbers in the RDC Application

- 15.2 Displaying Discrepancy IDs in the RDC Application

- 15.3 Debugging the Migration Utility

- 15.4 Debugging the Patient Data Report

- 15.5 RDC Log Files

- 15.5.1 Locating the WebLogic Server Log Files

- 15.5.2 Setting Up Debugging

- 15.5.2.1 Editing the logging.xml file for Debugging

- 15.5.2.2 Editing the URL for Debugging

- 15.5.3 Types of Log Files

- 15.5.3.1 RDC Application Pages Log Files

- 15.5.3.2 RDC Data Entry Window Log Files

- 15.5.3.3 Data Capture API (DCAPI) Logs

- 15.5.3.4 Data Capture API (DCAPI) Framework Logs

- 15.5.4 Enabling a SQL Trace for Searches

- 15.5.5 Error when a Failure Occurs during Data Entry

- 15.5.6 Locating Log Files for a Fatal Failure during Data Entry

- 15.5.7 Dump File for a Data Entry Fatal Failure Error

- 15.5.7.1 Location of the Dump File

- 15.5.7.2 Enabling Dump File Creation

- 15.5.7.3 Reading a Dump File

- 15.6 Debugging Performance Issues in the Data Entry Window

- 15.6.1 Performance Profiling for the Data Entry Client

- 15.6.2 Performance Profiling for Data Entry Server Code

- 15.7 Tracking Scalability Data for RDC

- 15.7.1 Enabling Tracking of Scalability

- 15.7.2 Viewing the Scalability Metrics

A Setting Up Database Connections

- A.1 Adding WebLogic Server Data Sources

- A.2 Add Service Name to tnsnames.ora

- A.3 Configure Maximum Connections

B Generating HTML DE and PDR Templates for Existing DCI Form Versions

- B.1 Creating User Roles that Can Upgrade DCI Forms Only

- B.2 Upgrading Existing DCI Form Versions for HTML DE and New PDRs

- B.3 Running the Upgrade Utility in Incremental Mode

C Troubleshooting

- C.1 CLOB Conversion Error Opening Data Entry Window

- C.2 Executable Creation Error Opening Data Entry Window

- C.3 Data Entry Window Doesn't Open

- C.4 RWServlet URL Connection Error

- C.5 Dcapi error saying dll already loaded

- C.6 Closing discrepancy of batch loaded CRF error

- C.7 Application Hangs When User Tries to Open a New Window

- C.8 Cannot Log In to Application

- C.9 Oracle Clinical or RDC Not Launching

- C.10 Cannot Stop Submitted Report Jobs from RDC Onsite

D Deploying Customizations

- D.1 Locating the olsardc.ear File

- D.2 Manually Extracting and Repacking the olsardc.ear File

- D.3 Deleting the Existing Deployment

- D.4 Redeploying RDC with Customizations

- D.5 Restarting the OPA Server

Glossary

List of Examples

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

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

- 5-1 Query to find DCIs for which the CRT requirement has changed

- 9-1 Using the Substitution Parameters for News Items

- 11-1 Creating a Dynamic User Link

- 11-2 Static Study Link

- 11-3 Static Site Link

- 11-4 Static Patient Link

- 15-1 Important Identifiers in the Dump File

List of Figures

- 1-1 RDC Administration Main Window

- 1-2 Oracle Clinical Main Window

- 2-1 Assigning Privileges to a User for a Particular Study

- 2-2 Data Entry Configuration Settings for RDC

- 3-1 The RDC Configurations Form

- 3-2 Configuration Settings Applicable to RDC

- 4-1 Defining the Reasons for a Manual Discrepancy

- 4-2 Defining the Reasons for Univariate Discrepancies

- 6-1 DCI Form Runtime Settings for RDC

- 6-2 DATA CHANGE REASON TYPE CODE Codelist

- 9-1 Reading the Daily News in RDC

- 9-2 News Definition for Remote Data Capture Form

- 11-1 Sample Customized Links on the Home Page

- 11-2 Links Displayed in the Patient Summary Report

- 11-3 Customizing Help for the CRF

- 11-4 Maintain Links Form

- 12-1 Custom Help Text for Fields in a CRF

- 12-2 Identifying the File Name of Individual Help Topics

- 13-1 Sample Patient Data Report

- 14-1 Sample PC Desktop Showing the desktoppdr Folder

- 15-1 Fatal Error Dialog Box with Log Code information

List of Tables

- 1-1 Default Database Roles Defined for RDC Users

- 2-1 Functional Privileges for RDC Users

- 2-2 Sample Privilege Assignments

- 2-3 Options for Opening the Maintain Access to DCIs within Study Form

- 3-1 Default Configurations for RDC

- 3-2 Unique Assignments to the Same Configuration

- 3-3 Example of Precedence and Parsing of Assignment Parameters

- 3-4 Valid Values for the Highlighting Scheme in the Data Entry Window

- 3-5 Typical Parameters in an rdcConfig.properties File

- 4-1 Default Entries for the DISCREPANCY REV STATUS CODE Codelist

- 4-2 Colors Used to Indicate Discrepancy Access Status

- 4-3 User Roles and the Default RDC Discrepancy Access Statuses

- 4-4 Default Entries for the DISCREPANCY ACTIONS DM Codelist

- 4-5 Values for the DISCREPANCY RESOLU TYPE CODE

- 6-1 Parameters in the ocl_utils.update_pat

- 6-2 Using DCI Book Assignment

- 6-3 Initial Values for the DATA CHANGE REASON TYPE CODE Codelist

- 6-4 Data Entry Preferences

- 7-1 RDC URL Parameters

- 9-1 Fields in the News Definition for Remote Data Capture Form

- 9-2 Substitution Parameters for News Items

- 10-1 Default Activities for RDC

- 10-2 RDC_ACTIVITIES Database Table

- 10-3 RDC_ACTIVITIES_TAGS Database Table

- 10-4 Default Activity Tags and Corresponding Functions

- 10-5 Parameters for the rdc_zf_surround_activitiy.setSearchCondition Procedure

- 10-6 SQL Statements to Calculate Counts

- 10-7 Functions Included in the RDC_USER_ACTIVITY_TAGS Package

- 11-1 Parameter Descriptions

- 11-2 Parameter Strings for Static Links

- 11-3 Dynamic Link Parameters

- 13-1 Settings for the Patient Data Report

- 14-1 Parameters for the RunPDR Command

- 14-2 Parameters for the RunBlankCasebook Commands

- 15-1 Summary of RDC Log Files

- 15-2 Errors and the Text Added to the Message

Preface

The Oracle Clinical Remote Data Capture Onsite Administrator's Guide describes how to set up, configure, and customize the Oracle Clinical Remote Data Capture application. Your administration tasks include defining access privileges, creating custom configurations, customizing data entry behavior and other features, and controlling the content of Patient Data Reports.

This preface contains the following topics:

- Audience

- Documentation Accessibility

- Finding Information and Patches on My Oracle Support

- Finding Oracle Clinical Documentation

- Conventions

Audience

This document is intended for data managers and system administrators who are responsible for managing, customizing, and maintaining the RDC application.

You use a variety of tools and applications to complete the system administration tasks for RDC. This document assumes you have a general understanding of using Oracle Clinical, Microsoft Windows, text editors, and PL*SQL procedures.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Finding Information and Patches on My Oracle Support

Your source for the latest information about Oracle Clinical is Oracle Support's self-service Web site My Oracle Support (formerly MetaLink).

Before you install and use Oracle Clinical Remote Data Capture, always visit the My Oracle Support Web site for the latest information, including alerts, White Papers, installation verification (smoke) tests, bulletins, and patches.

Creating a My Oracle Support Account

You must register at My Oracle Support to obtain a user name and password account before you can enter the Web site.

To register for My Oracle Support:

1. Open a Web browser to https://support.oracle.com.

2. Click the Register link to create a My Oracle Support account. The registration page opens.

3. Follow the instructions on the registration page.

Signing In to My Oracle Support

To sign in to My Oracle Support:

1. Open a Web browser to https://support.oracle.com.

2. Click Sign In.

3. Enter your user name and password.

4. Click Go to open the My Oracle Support home page.

Finding Information on My Oracle Support

There are many ways to find information on My Oracle Support.

Searching by Article ID

The fastest way to search for information, including alerts, White Papers, installation verification (smoke) tests, and bulletins is by the article ID number, if you know it.

To search by article ID:

1. Sign in to My Oracle Support at https://support.oracle.com.

2. Locate the Search box in the upper right corner of the My Oracle Support page.

3. Click the sources icon to the left of the search box, and then select Article ID from the list.

4. Enter the article ID number in the text box.

5. Click the magnifying glass icon to the right of the search box (or press the Enter key) to execute your search.
The Knowledge page displays the results of your search. If the article is found, click the link to view the abstract, text, attachments, and related products.

Searching by Product and Topic

You can use the following My Oracle Support tools to browse and search the knowledge base:

- Product Focus — On the Knowledge page under Select Product, type part of the product name and the system immediately filters the product list by the letters you have typed. (You do not need to type "Oracle.") Select the product you want from the filtered list and then use other search or browse tools to find the information you need.

- Advanced Search — You can specify one or more search criteria, such as source, exact phrase, and related product, to find information. This option is available from the Advanced link on almost all pages.

Finding Patches on My Oracle Support

Be sure to check My Oracle Support for the latest patches, if any, for your product. You can search for patches by patch ID or number, or by product or family.

To locate and download a patch:

1. Sign in to My Oracle Support at https://support.oracle.com.

2. Click the Patches & Updates tab. The Patches & Updates page opens and displays the Patch Search region. You have the following options:

- In the Patch ID or Number field, enter the number of the patch you want. (This number is the same as the primary bug number fixed by the patch.) This option is useful if you already know the patch number.

- To find a patch by product name, release, and platform, click the Product or Family link to enter one or more search criteria.

3. Click Search to execute your query. The Patch Search Results page opens.

4. Click the patch ID number. The system displays details about the patch. In addition, you can view the Read Me file before downloading the patch.

5. Click Download. Follow the instructions on the screen to download, save, and install the patch files.

Finding Oracle Clinical Documentation

The latest product documentation for Oracle Clinical and Oracle Clinical Remote Data Capture Onsite is available on the Oracle Help Center at https://docs.oracle.com/health-sciences/oc-rdc-52/index.html">>https://docs.oracle.com/health-sciences/oc-rdc-52/index.html.

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

1 Getting Started with Administration Tasks

System administration for Oracle Clinical Remote Data Capture (RDC) requires that you perform certain tasks in the RDC Administration application and other tasks in Oracle Clinical. Using these administration applications, you can configure and customize RDC to suit the purposes of your organization.

This chapter includes the following topics:

- Section 1.1, "About Administrator Privileges for Maintaining RDC"

- Section 1.2, "Starting the RDC Administration Application"

- Section 1.3, "Starting the Oracle Clinical Application"

- Section 1.4, "Setting Web Command Access"

- Section 1.5, "Stop the WebLogic Admin Server"

1.1 About Administrator Privileges for Maintaining RDC

Any user who wants to be able to define, configure, and maintain the features in RDC must have RDC administrator privileges.

By default, the following user roles have the required administrator privileges for defining and maintaining RDC:

- RXC_ADMIN

- RXC_SUPER

- RXC_SUPER_NOGL

- RXC_DES

- RXC_DMGR

See the Oracle Clinical Administrator's Guide for information on creating user accounts and user roles with RDC administrator privileges.

1.1.1 About Database Roles for RDC Users

You must explicitly grant every RDC user at least one database role. You can use the predefined database roles listed in Table 1-1, selecting the role that matches the user's job function, or define additional database roles if you need to further fine-tune security privileges.

These database roles are mapped to user roles in the USER_GROUP_ROLES installation reference codelist. Those roles allow users to define security privileges and to customize various aspects of the RDC user interface.

See the Oracle Clinical Administrator's Guide for information on granting database roles to user accounts and creating additional database roles.

Table 1-1 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

1.1.2 About User Roles with Limited Administrator Privileges

Users granted administrator privileges in Oracle Clinical can define, configure, and maintain all the features in RDC. In addition to those roles, you can identify a different set of user roles with limited administrator privileges.

Specifically, you can:

- Create a user role where the user has the privilege to define news content, but not perform other administrator tasks

- Create a user role where the user has the privilege to upgrade DCI Forms, but not perform other administrator tasks

Note that the process you use to create the user roles that can define news content or upgrade DCI Forms is different from the process for creating the user roles for other administrative privileges.

For more information on defining user roles with these limited administrator privileges, see the following sections:

- Section 9.2, "Creating User Roles that Can Define News Items Only"

- Section B.1, "Creating User Roles that Can Upgrade DCI Forms Only"

1.2 Starting the RDC Administration Application

To access the Launch page for the Oracle Clinical Remote Data Capture Administration application, open a Web browser and enter the URL for your RDC installation. For example:

https://computer.mycompany.com/opa52/rdcadmin.htm

From the Launch page, you can:

- Log in to the RDC Administration application

- Change your login password

- Navigate to documentation, software downloads, the Oracle Health Sciences Web site, and the Oracle Health Sciences User Group Web site

1.2.1 RDC Administration Main Window

Figure 1-1 illustrates the RDC Administration Main window.

Figure 1-1 RDC Administration Main Window

You can use the menu commands to enter and execute database queries, to insert and remove records, and to go to the next and previous fields, records, and blocks. The icons on the toolbar provide shortcuts to many of these features. For more information on using these standard Oracle Clinical tools, see Oracle Clinical Getting Started.

The Navigator pane provides access to the following options for configuring and customizing the RDC application:

- The Study Security and Site Security options let you assign privileges to users on a study or site basis. Privileges give RDC users the right to access certain data and CRFs, as well as the permission to perform a certain task or an action on the database. See Chapter 2, "Securing Remote Data Capture" for more information.

- The Links option lets you configure URLs that RDC displays in the Links section on the Home page. Any information that can be made available through a URL can be made accessible to RDC users. See Chapter 11, "Configuring Links" for more information.

- The Configurations option lets you define a collection of settings that customizes certain features in RDC, and then assign the configuration to one or more users. Configurations give you the power to make features available depending on users, the studies they access, and their user role. See Chapter 3, "Customizing with RDC Configurations" for more information.

- The News option lets you enter messages, such as protocol changes or upcoming deadlines, that the study sponsor wants to communicate to its users. RDC displays the headlines in the News section on the Home page. See Chapter 9, "Configuring News" for more information.

1.2.2 About Maintain Mode versus Query Mode

In the Navigator pane, the Maintain options let you define and update settings. Query mode provides access to the same options. However, in Query mode, you can access and view — but not add or modify — the settings.

1.3 Starting the Oracle Clinical Application

System administration for RDC requires that you perform certain tasks in the Oracle Clinical application. To access the Launch page for the Oracle Health Sciences Applications, open a Web browser and enter the URL for your Oracle Clinical installation. For example:

https://computer.mycompany.com/opa52/launch.htm

The Launch page is similar to the RDC Administration Launch page. You can log in to Oracle Clinical; change your password; and access product documentation, software downloads, the Oracle Health Sciences Web site, and the Oracle Health Sciences User Group Web site. Figure 1-2 shows the Oracle Clinical Main window.

Figure 1-2 Oracle Clinical Main Window

In Oracle Clinical, you use options in Admin, Definition, Design, and Conduct to define and configure settings for RDC. Many of the settings apply to Oracle Clinical as well; some settings apply to RDC only.

- Using reference codelists, you define the reasons, review statuses, access statuses, and allowed actions for discrepancies. See Chapter 4, "Configuring Discrepancy Management" for more information.

- Using a combination of reference codelists and Oracle Clinical forms, you can customize the behavior of RDC during data entry. For example, you can allow HTML data entry for RDC; control the display of conditional blocks, dates, and lists of values; and suppress prompts and warnings. See Chapter 6, "Customizing Data Entry Behavior" for more information.

- You can control what information, such as bookmarks, audit history, and approval data, to include in a Patient Data Report. See Chapter 13, "Configuring Settings for Reports" for more information.

1.4 Setting Web Command Access

Required Change You must edit rwservlet.properties; otherwise report submissions and view job status URLs don't work.

1. Log on to the Application Server.

2. Go to DomainHome\config\fmwconfig\servers\WLS_REPORTS\applications\reports_11.1.2.1.0\configuration

3. Open rwservlet.properties in a text editor and add the following line below the <inprocess> parameter:
<webcommandaccess>L2</webcommandaccess>

For more information on modifying the system files, see Chapter 7, "Customizing RDC on the Application Server" and Chapter 15, "Collecting Debug Data."

In addition, before modifying a system file, you must stop WebLogic Admin Server. See Section 1.5, "Stop the WebLogic Admin Server" for more information.

1.5 Stop the WebLogic Admin Server

To stop WebLogic Admin Server:

1. Close the command shell in which the WebLogic Admin Server is running.

2. Close any open DOS windows.

3. Go to the Windows Control Panel, then Services, and turn off the WebLogic Admin Server.

For further information on the WebLogic Admin Server, see the Oracle® Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server 11g Release 1 (10.3.6) at http://docs.oracle.com/cd/E23943_01/web.1111/e13740/toc.htm

2 Securing Remote Data Capture

Using forms and settings in either the RDC Administration application or the Oracle Clinical application, you can oversee RDC security, configure certain application components, and maintain session settings for RDC users.

This chapter includes the following topics:

- Section 2.1, "About Security Privileges"

- Section 2.2, "Assigning Study and Site Security Privileges"

- Section 2.3, "Granting Oracle Clinical Users Access to RDC"

- Section 2.4, "Managing Security with Data Entry Configuration Settings"

- Section 2.5, "Restricting Actions Against Locked CRFs"

- Section 2.6, "Restricting Access to Data Collection Instruments (DCIs)"

2.1 About Security Privileges

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

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

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

You can assign privileges on a study basis or a study site basis. For example, you can grant a user BROWSE access to all sites in the study, and then grant the same user UPDATE privileges for one site.

Table 2-1 describes the privileges that you can assign to users.

Note:
Some privileges also apply to Oracle Clinical users who have access to the Discrepancy Management form.
For more information, see ”Configuring Discrepancy Management” in the Oracle Clinical Administrator's Guide.

2.1.1 Minimum Requirement for Privileges

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

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

Note that BROWSE does not include BRW_BATCH.

Note:
In addition to granting privileges, you must grant a role to each user.

Table 2-1 Functional Privileges for RDC Users

Privilege

Access Granted

Applies To…

BROWSE

Provides read-only access to manually-entered data.

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

- RDC

- Oracle Clinical Discrepancy Management form

BRW_BATCH

Provides read-only access to batch-loaded data.

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

- RDC

- Oracle Clinical Discrepancy Management form

BROWSE_VERIFY

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

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

- RDC

BROWSE_SDVPLAN

Provides read-only access to SDV plan.

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

- RDC

BROWSE_REVIEW

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

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

- RDC

Update privileges for custom review types

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

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

- RDC

UPDATE

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

The UPDATE privilege includes the privileges defined by UPD_DISCREP.

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

- RDC

- Oracle Clinical Discrepancy Management form

UPD_BATCH

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

The UPD_BATCH privilege includes the privileges defined by BRW_BATCH.

- RDC

- Oracle Clinical Discrepancy Management form

UPD_DISCREP

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

- RDC

- Oracle Clinical Discrepancy Management form

UPDATE_SDVPLAN

Lets the user update SDV plans.

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

- RDC

ADMIN_SDVPLAN

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

The ADMIN_SDVPLAN privilege includes the privileges defined by BROWSE_SDVPLAN

- RDC

VERIFY

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

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

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

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

- RDC

APPROVE

Lets the user electronically sign CRFs.

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

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

- RDC

UPD_LOCK_OC

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

- Oracle Clinical only

2.1.2 Privileges and Batch-Loaded CRFs

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

- BRW_BATCH

- UPD_BATCH

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

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

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

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

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

2.1.3 Site Privileges Take Precedence Over Study Privileges

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

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

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

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

- UPDATE privilege at the study level

- BROWSE privilege for the Site003 site

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

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

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

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

- UPDATE at the study-level, and

- UPDATE and APPROVE at Site001 and Site 002

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

Table 2-2 Sample Privilege Assignments

Job

Study Level

Site Level

Investigator

BROWSE

APPROVE

Data entry personnel

—

UPDATE, BRW_BATCH

CRA

BROWSE, BRW_BATCH

UPD_DISCREP, VERIFY

Data manager

BROWSE, BRW_BATCH, UPD_DISCREP

—

2.2 Assigning Study and Site Security Privileges

To use the Study Security and Site Security options, you must have one of the following privileges:

- RXC_ADMIN

- RXC_SUPER

- RXC_SUPER_NOGL

Other users who have study access can use the Query Study Security and the Query Site Security options to view the study and site security forms, but cannot update any information.

2.2.1 Opening the Security Privileges Forms

You can define and maintain users' study and site privileges either from RDC Administration or from Oracle Clinical.

In RDC Administration:

- To define study privileges, navigate to Maintain, and then select Study Security.

- To define site privileges, navigate to Maintain, and then select Site Security.

In Oracle Clinical:

- To define study privileges, navigate to Admin, Users and Roles, and then select Study Security.

- To define site privileges, navigate to Admin, Users and Roles, and then select Site Security.

2.2.2 Configuring Study and Site Security Privileges

Once you open either the Maintain Access to Studies form or the Maintain Access to Sites within a Study form, you can use the standard menu commands, toolbar icons, or shortcut keys to:

- Query for one or more records. You can use the % sign as a wildcard search character.

- Add a new record or update existing records.

- Delete one or more records.

- Switch to a different study or site.

For the Study field, Site field, and User field, you can type directly into the field. You can also open a list of valid values and select from the list.

To add or modify the privileges for a user:

1. Open either RDC Administration or Oracle Clinical.

- In RDC Administration, navigate to Maintain.

- In Oracle Clinical, navigate to Admin, Users and Roles.

2. Open the correct form:

- To grant privileges to a user for a particular study, select Study Security.

- To grant privileges to a user for a particular site, select Site Security.

3. Query for a particular record or query all records and navigate to the record you want to update. Alternatively, press F6 to insert a blank row and add a new record.

4. Click the Privilege column for the user whose privileges you want to update. The dialog box for configuring privileges opens. See Figure 2-1.

5. Select the privileges to assign to the user:

- To select one privilege, click that privilege.

- To select several privileges, Ctrl-click each privilege. Ctrl-click also toggles the selection on and off.

- To select a range, Shift-click the first and last privilege in the range.

6. Click OK to save the privileges for the selected user. Add or modify privileges for other users, as appropriate. Save your changes when finished.

Figure 2-1 Assigning Privileges to a User for a Particular Study

2.2.3 Granting Administrator Privileges to Individual Users

You can grant administrator privileges to individual users for particular studies or sites. For example, you can give users with study design roles (RXC_DES and RXC_DMGR) administrator privileges only for the studies they manage.

Note that the administrator privilege alone does not include any access to patient data. You must also grant the user at least the BROWSE privilege.

To grant administrator privileges to a user:

1. Open either RDC Administration or Oracle Clinical.

- In RDC Administration, navigate to Maintain.

- In Oracle Clinical, navigate to Admin, Users and Roles.

2. Open the correct form:

- To grant administrator privileges to a user for a particular study, select Study Security. Execute a query for the user or study.

- To grant administrator privileges to a user for a particular site, select Site Security. The system lists the available sites and defined users.

3. Enable the appropriate Admin? check box to grant administrator privileges.

2.3 Granting Oracle Clinical Users Access to RDC

A user who has access to a study in Oracle Clinical does not automatically have access to that study in RDC unless you use the Study Security form in the RDC Administration application to assign specific privileges to the user.

Alternatively, you can use the DMGR RDC ACCESS short value in the OCL_STATE local reference codelist to automatically grant an Oracle Clinical user access to the studies in RDC.

Users with the Superuser flag selected in the Oracle Accounts form in Oracle Clinical always have access to all studies in both Test and Production modes.

To automatically grant an Oracle Clinical user access to RDC:

1. Define the study or studies that the user can access. See the Oracle Clinical Administrator's Guide for more information.

2. Open Oracle Clinical.

3. Navigate to Admin, Reference Codelists, and then select Local Codelists.

4. Query for the OCL_STATE local reference codelist:

1. Enter OCL_STATE in the Name field.

2. Press F8 to execute the query.

5. Scroll to the DMGR RDC ACCESS short value.

6. Set the long value to YES.

7. Save your changes.

A user who is granted RDC study access in this manner has all RDC privileges defined in Table 2-1 except the APPROVE, BROWSE_VERIFY, and VERIFY privileges. (The UPD_LOCK_OC privilege, which is an Oracle Clinical privilege only, is also excluded). You can restrict such a user's access to RDC by limiting privileges at the study or site level.

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 access to the study as well, in both Test and Production modes.

When set to NO, a user granted access to a study in Oracle Clinical does not automatically have access to that study in RDC. You can use the Study Security form in the RDC Administration application to assign specific privileges to the user.

2.4 Managing Security with Data Entry Configuration Settings

As shown in Figure 2-2, the Maintain Installation Configuration form has two data entry configuration settings that are relevant to RDC. These settings let you:

- Control whether a user can resolve discrepancies at the time the discrepancy is raised.

- Enable privileged update for the user. With privileged update enabled, the user can:

- Update data and discrepancies for locked documents (RDCMs and RDCIs)

- Override and update protected repeating defaults

You can define the configuration at the local database level. You can then override the configuration settings at the study or user level.

Note:
Most settings in the Maintain Installation Configuration form do not apply to RDC. With the exception of the Resolve Discrepancies in Data Entry setting and the Privileged Update setting, all other settings in the form pertain only to Oracle Clinical and RDC PDF data entry.

2.4.1 Changing the Data Entry Configuration Settings

You have two ways to change the data entry configuration settings: by using a form or by using a reference codelist.

You have the option of changing these settings at the local database level either by using the Maintain Installation Configuration form or by using the OCL_DE_CONFIG local reference codelist.

To use the Maintain Installation Configuration form:

1. Open Oracle Clinical.

2. Navigate to Admin, DE Admin, and then select DE Config Settings. See Figure 2-2.

Figure 2-2 Data Entry Configuration Settings for RDC

2.4.2 Authority to Resolve Discrepancies upon Discrepancy Creation

Use the Resolve Discrepancies in Data Entry setting to define whether the user has permission to resolve discrepancies at the time the discrepancy is created.

- If Enabled, the user can resolve discrepancies during data entry and route discrepancies for further action by another user. The default value is Enabled.

- If Disabled, routing actions are enabled at discrepancy creation time, but resolution actions are not made available.

2.4.3 Authority to Update Locked CRFs and Override Repeating Defaults

Use the Privileged Update setting to define whether the user can perform the following actions:

- Update data and discrepancies for locked RDCMs and RDCIs

- Override protected repeating defaults.

- Exceed the maximum number of repeats defined for a repeating question group, even if Enforce Repeats is set. Note that this action pertains only to Oracle Clinical.

You can enable or disable the Privileged Update setting. The default value is Disabled.

See Section 2.5, "Restricting Actions Against Locked CRFs" for information on how you can prevent users from approving CRFs, verifying CRFs, and updating discrepancies for locked documents.

2.4.4 Modifying Data Entry Configurations at the Database, Study, and User Levels

You can set the two Data Entry Configuration settings — Resolve Discrepancies in Data Entry and Privileged Update — at the user level, the study level, or the local database level.

At the user level and the study level, you can select Not Set as the value for these settings. If you select Not Set at the user level, then RDC uses the value set at the study level. If neither the study nor the user level is set, then RDC uses the value set for the local database.

With this hierarchy, it is best to define the configuration at the local database level, and then override at the study or user level.

2.4.4.1 At the Local Database Level

To define the data entry configuration setting at the local database level, you can use the Maintain Installation Configuration form or the OCL_DE_CONFIG local reference codelist.

To navigate to the Maintain Installation Configuration form for the local database:

1. Open Oracle Clinical.

2. Navigate to Admin, DE Admin, and then select DE Config Settings.

3. Navigate to the setting that you want to modify.

4. Change the value to Enabled or Disabled.

5. Save your changes.

Alternatively, to make the same changes using the OCL_DE_CONFIG codelist:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Local Codelists.

3. Query for the OCL_DE_CONFIG codelist:

1. Enter OCL_DE_CONFIG in the Name field.

2. Press F8 to execute the query.

4. Scroll to and modify the values as follows:

- To let the user resolve discrepancies at the time the discrepancy is raised, set the DISC RES IN DE value to Y.

- To enable privileged update, set the PRIV UPDATE value to Y.

5. Save your changes.

2.4.4.2 At the Study Level or the User Level

To define the data entry configuration settings at either the study or the user level:

1. Open Oracle Clinical.

2. Navigate to the correct configuration form as follows:

- To change the settings at the study level, navigate to Conduct, Security, and then select Clinical Study States.

- To change the settings at the user level, navigate to Admin, Users and Roles, and then select Oracle Accounts.

3. Query for the study or user that you want to update.

1. Press F7 to enter a query.

2. Specify your search criteria. You can use the % wildcard.

3. Press F8 to display the studies or users that match your criteria.

4. Select the applicable study or user.

5. Open the Special menu, and then select DE Config.

6. Navigate to the setting that you want to modify.

7. Change the value to Enabled, Disabled, or Not Set.

- At the study level, you can set any value to Not Set. For any setting with a Not Set value, RDC uses the value at the local database level.

- At the user level, you can set any value to Not Set. For any setting with a Not Set value, RDC first looks at the value set at the study level. If the value is Not Set, RDC uses the value at the local database level.

8. Save your changes.

2.5 Restricting Actions Against Locked CRFs

By default, RDC restricts access to locked CRFs.

You can use the RSTRCT LCKD CRF setting in the OCL_DE_CONFIG local reference codelist to control a users ability to:

- Update the discrepancies in a locked CRF

- Verify a locked CRF

- Approve a locked CRF

Even if you change the restriction access, users can work with a locked CRF only if they have the proper privileges: UPD_DISCREP, VERIFY, or APPROVE.

To change the restriction access to locked CRFs:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Local Codelists.

3. Query for the OCL_DE_CONFIG codelist:

1. Enter OCL_DE_CONFIG in the Name field.

2. Press F8 to execute the query.

4. Scroll to the RSTRCT LCKD CRF short value.

5. Set the long value. Do you want to restrict access to locked CRFs?

- Y — Specifies that users cannot update discrepancies for a locked CRF, verify a locked CRF, or approve a locked CRF unless the CRF is specifically unlocked for them.

- N — Specifies that any user with UPD_DISCREP privileges can work on discrepancies in a locked CRF, any user with VERIFY privileges can verify a locked CRF, and any user with APPROVE privileges can approve a locked CRF.

6. Save your changes.

2.6 Restricting Access to Data Collection Instruments (DCIs)

Recall that the DCIs you create in Oracle Clinical are the CRFs that users work with in the RDC application. You can limit which DCIs a users can access when they are working in RDC.

To limit DCI access, you can:

- Specify the limits by user role and by study.

- Specify the limits in inclusive or exclusive terms. In other words, you can specify which DCIs to include and which DCIs to exclude.

You first specify the default DCI Access at the installation level. For each user role, you define access as:

- UNRESTRICTED (that is, all DCIs are visible to the user). If you do not define any exceptions to this unlimited access, the level of access depends upon privileges granted to the user at the study and site level.

- RESTRICTED (that is, no DCIs are visible to the user).

Once you define the default DCI access, you can override these settings at the study level. For any user role, you can specify a list of DCIs that the user can access (an INCLUSION list) or cannot access (an EXCLUSION list).

2.6.1 Changing the Default Access to DCIs

RDC includes a default set of user roles. For each user role, Oracle Clinical sets the default value for DCI access to UNRESTRICTED. In other words, all users can access all DCIs regardless of user role. You use the Maintain DCI Access by Role form to limit the DCIs a user can access.

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 the RDC application. You must define the default access to DCIs for every user role you plan to assign.

The default DCI access specification applies to both production mode and test mode.

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:

1. Open Oracle Clinical.

2. Navigate to Admin and then select Users and Roles.

3. 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.

4. 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.

5. 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.

6. Continue to enter each user role and the type of DCI access allowed.

7. 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 after an upgrade, 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.

2.6.2 Defining DCI Access within a Study

After you define the default DCI access for a user role, you can refine the access on a study-by-study basis. You define exceptions to the default DCI access. For example:

- You can define one or more specific DCIs that users with the selected role cannot access. When you exclude a DCI, you can also specify whether the user role does not see the DCI at all or whether the user role can open the DCI in browse mode only.

- You can define one or more DCIs that users with the selected role can access. When you include a DCI, you can also specify whether the user role can open the DCI with the default study/site privileges or with browse only privileges.

If a user does not have access to a study based on the defined study-level or site-level access, the Study DCI Access does not provide the user with access to the DCI or to the study.

2.6.2.1 Opening the Maintain Access to DCIs within Study Form

Table 2-3 describes the various ways that you can open the Maintain Access to DCIs within Study form.

Table 2-3 Options for Opening the Maintain Access to DCIs within Study Form

If you want to…

For this mode…

Open Oracle Clinical and navigate to…

Define DCI access for a study

Production

Definition, DCIs, DCI Access

View the DCI access for a study

Production

Definition, DCIs, Qry DCI Access

Define DCI access for a study

Test

Definition, Test a study, DCI Access

2.6.2.2 Defining Inclusions and Exclusions for DCI Access

To define the DCI access for a study:

1. Open Oracle Clinical.

2. Navigate to Definition, DCIs, and then select DCI Access.

3. Enter the name of the study for which you want to define DCI access. Oracle Clinical opens the Maintain Access to DCIs within Study form.

4. 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. Note that the list also displays the default access.

5. Enter the DCI List Type for the selected user role. Valid entries are:

- INCLUSION — Indicates that the user role will be able to access only the DCIs listed in the DCI Name column. The user role has no access to unlisted DCIs.

- EXCLUSION — Indicates that the user role cannot access the DCIs listed in the DCI Name column. All other DCIs are accessed according to the user's study/site privileges.

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.

6. Click the DCI Name field and then enter the name of the DCI that you are including or excluding.
Alternatively, you can leave the DCI Name column empty. An empty DCI list is interpreted differently, depending on whether you are defining an INCLUSION or EXCLUSION list.

- If the DCI List Type is set to INCLUSION and the DCI Name column is empty, then the user has access to no DCIs for this study. Use this approach when the default DCI access for the user role is UNRESTRICTED, but for a specific study the user role has access to no DCIs.

- If the DCI List Type is set to EXCLUSION and the DCI Name column is empty, then the user has access to all DCIs for this study. Use this approach when the default DCI access for the user role is RESTRICTED, but for a specific study the user role has access to all DCIs.

Note that for individual users, you usually define the same access with study security.

7. Click the Access field and then enter the type of access to allow for this DCI. Your options vary depending on whether you are including or excluding access to the DCI.
If the DCI List Type is set to INCLUSION, you can select:

- Default study/site privileges — Indicates that the DCI is accessed according to the user's study/site privileges.

- Browse — Indicates that the user role can open and view the DCI only in browse mode.

If the DCI List Type is set to EXCLUSION, you can select:

- None — Indicates that the user role cannot access the DCI.

- Browse — Indicates that the user role can open and view the DCI only in browse mode.

8. Continue to define the DCIs that this user role can access (include and exclude). Save your changes when you are finished.

3 Customizing with RDC Configurations

A configuration is a collection of settings that customizes certain features in the RDC application. For example, the configuration settings let you hide the group verify option, customize the Links label, and set the default highlighting scheme for the Data Entry window.

Using the RDC Administration application, you create a configuration, define its settings, and then assign the configuration to one or more users. When a user logs in to the application, RDC checks the assignments and loads the correct configuration for that user.

Configurations give you the power to make features available depending on users, the studies they access, and their user role.

This chapter includes the following topics:

- Section 3.1, "About the RDC Configurations"

- Section 3.2, "Managing RDC Configurations"

- Section 3.3, "Configuration Settings for RDC"

- Section 3.4, "Required Parameters in an rdcConfig.properties File"

3.1 About the RDC Configurations

Using the RDC Configurations form in the RDC Administration application, you can create one or more configurations. Figure 3-1 shows the RDC Configurations form and summarizes the key steps to creating and assigning configurations.

The settings in a configuration let you:

- Specify whether to show or hide the options for changing preferences, for performing group verifications, and for performing group approvals

- Specify whether to show or hide the Save Complete prompt and the Validation Error alert

- Customize the label for the Links section on the home page, the display of time stamps, and the default highlighting scheme for the Data Entry window

- Configure how RDC uses Oracle Clinical rules and entered CRFs

After you create a configuration and define its settings, you use the assignment parameters to assign the configuration to one user, several users, or all users. You assign a configuration based on a combination of user name, study name, and user role.

When a user logs in to the application, RDC checks the assignments and loads the correct configuration for that user.

Figure 3-1 The RDC Configurations Form

3.1.1 Default Configurations

Table 3-1 lists the default configurations available after you install RDC.

Table 3-1 Default Configurations for RDC

Configuration Name

Description

RDC CONFIGURATION

Default settings for users, if no other configuration is appropriate.

RDC CONFIGURATION CRA

Default settings for the Clinical Research Associate (CRA) role.

RDC CONFIGURATION INV

Default settings for the investigator role.

RDC CONFIGURATION SITE

Default settings for the site user role.

3.1.2 Assignment Parameters

When a user logs in to the application, RDC uses the three assignment parameters to apply the correct configuration:

- User Name

- Study Name

- User Role

3.1.2.1 Default Value (%) for Assignment Parameters

The percent sign (%) is a wildcard character meaning include all. For example, % in the User Name field includes all user names.

The default value for each assignment parameter is the percent sign (%).

3.1.2.2 Assigning Configurations

After you create a new configuration and define its settings, you assign the configuration to one user, several users, or all users. You can make more than one assignment to a configuration. The configuration uses the same name and the same settings, but the assignment parameters are different for each instance of the configuration.

For example, you can have many instances of a configuration named RDC CONFIGURATION CRA, as long as at least one assignment parameter for each instance is different. See Table 3-2.

Table 3-2 Unique Assignments to the Same Configuration

Configuration Name

User Name

Study Name

User Role

RDC CONFIGURATION CRA

%

%

CRA

RDC CONFIGURATION CRA

%

STUDY03

%

RDC CONFIGURATION CRA

%

STUDY11

%

RDC CONFIGURATION CRA

JSMITH

%

%

RDC CONFIGURATION CRA

JDOE

%

%

Based on the assignments defined in Table 3-2, RDC assigns the RDC CONFIGURATION CRA under the following circumstances:

- To all users assigned the CRA role, regardless of the study they access

- To all users who access STUDY03 or STUDY11, regardless of their assigned role

- To users JSMITH and JDOE, regardless of the study accessed or their assigned role

3.1.2.3 Precedence and Parsing of Assignment Parameters

When a user starts a session, RDC uses the three assignment parameters to apply the correct configuration. RDC parses the assignment parameters for all configurations in the following order:

- First by user name

- Then by study name

- Finally by user role

In other words, study takes precedence over role, and user takes precedence over study and role. As soon as it matches one of the parameters to the user, RDC assigns the corresponding configuration to the user.

For example, suppose you set up the configurations listed in Table 3-3.

Table 3-3 Example of Precedence and Parsing of Assignment Parameters

Configuration Name

User Name

Study Name

User Role

RDC CONFIGURATION STUDY03

%

STUDY03

%

RDC CONFIGURATION JDOE

JDOE

%

%

Note that the first configuration, RDC CONFIGURATION STUDY03, is set for all users of any role who access Study03. The second configuration, RDC CONFIGURATION JDOE, is set for the user, JDOE.

When JDOE accesses Study03, the RDC CONFIGURATION JDOE configuration takes precedence because it corresponds at the user name level, and RDC loads that configuration. If another user starts a session and accesses Study03, RDC loads RDC CONFIGURATION STUDY03.

In a similar manner, the default configurations that are installed with RDC (see Table 3-1) are invoked based on the role associated with each user:

- If the user is assigned the CRA, INV, or SITE user role, RDC uses the associated configuration.

- If the user is not associated with one of these roles, RDC uses the RDC CONFIGURATION, which is the default configuration.

3.2 Managing RDC Configurations

To manage and customize configurations for the RDC application, you need to know how to:

- Open and use the RDC Configurations form

- Create a new configuration

- Assign configurations to users

- Delete assignments and configurations

3.2.1 Opening and Using the RDC Configurations Form

The RDC Configurations form (see Figure 3-1) lists the current configurations, along with the settings and assignments defined for the each configuration.

To open the RDC Configurations form:

1. Open the RDC Administration application.

2. Select Maintain, and then select Configurations.

Tips for working with the RDC Configurations form:

- You can enter and execute queries to view a subset of the configurations, users, studies, or roles. Press F7 to enter a query; press F8 to execute the query. You can use the wildcard character (%) when entering queries.

- You can use the menu, the toolbar icons, and the keyboard to access commands. Open the Help menu and then select Key Definitions to view a description of the available keyboard commands.

- Once you position the cursor in an input field, you can press F9 to display the list of valid values for that field. Alternatively, you can use the menu command, the toolbar icon, or the List of Values button to display the valid values for a field.

3.2.2 Creating a New Configuration

Recall that a configuration is a collection of settings that control which features of the RDC application a user can view or access. The settings customize the RDC features and functionality available to the users who are assigned to the configuration.

When you create a new RDC configuration, you specify a unique name for the configuration. In addition, you specify an existing configuration on which to base your new configuration.

Your new configuration:

- Inherits the configuration settings from the base configuration you select. You can change the settings for your new configuration at any time without affecting the settings of the selected base configuration.

- Is automatically assigned to all users, all studies, and all roles. (That is, the assignment parameters are set to the percent sign (%) wildcard, which is the default value and means ALL.) You can change the default assignment. You can also create a variety of new assignments for your configuration.

To create a new configuration:

1. Open the RDC Administration application.

2. Select Maintain, and then select Configurations.

3. Click Create.

4. Complete the Create New Configuration dialog box as follows:

1. Enter a unique text string for the name of your configuration.

2. Click the Based on field and then select an existing configuration from the list to use as the base for your new configuration.
You can leave the field blank or select DEFAULT to base your new configuration on the default configuration named RDC CONFIGURATION.

5. Click OK.

6. Click Yes to create the new configuration. The system inserts your new configuration into the Configuration Name list.
Once you create a new configuration, you need to:

- Specify the settings for the configuration. See Section 3.2.3, "Specifying the Settings for a Configuration" for details.

- Modify the default assignment parameters to assign the configuration to one, some, or all users. See Section 3.2.4, "Assigning Configurations to Users" for details.

3.2.3 Specifying the Settings for a Configuration

When you change the settings of a configuration, the change affects all users assigned to that configuration.

To change the settings in a configuration:

1. Open the RDC Administration application.

2. Select Maintain, and then select Configurations.

3. Select the configuration whose settings you want to change. Enter and execute a query, if necessary, to search for the configuration.

4. Scroll through the Configuration Settings list and modify the values relevant to RDC. You can press F9 to view a list of valid values for the selected field.
For a description of each setting and its valid values, see Section 3.3, "Configuration Settings for RDC."

5. Save your changes.

3.2.4 Assigning Configurations to Users

After you create a new configuration and define its settings, you assign the configuration to one user, several users, or all users. When a user logs in to the application, RDC checks the assignments and loads the configuration assigned to that user.

You use the User Name, Study Name, and User Role fields to define and modify the assignments for a configuration. You can:

- Modify the existing assignments for a configuration.

- Create new assignments for a configuration. Creating new assignments lets you assign the same configuration to different sets of users.

3.2.4.1 Modifying the Existing Assignments for a Configuration

By default, the system automatically assigns a newly-created configuration to all users, all studies, and all roles. Note that the User Name, Study Name, and User Role fields are set to the percent sign (%) wildcard, which is the default value and means ALL.

After you create a new configuration, you should modify the default assignments.

To modify the existing assignments for a configuration:

1. Open the RDC Administration application.

2. Select Maintain, and then select Configurations.

3. Place the cursor on the row of the configuration you want to modify. Enter and execute a query, if necessary, to search for a subset of configurations.

4. Select the Assignment Parameters fields to modify.

5. Click the List of Values button or press F9 to view a list of valid values for the selected field. Use the Find field, if necessary, to search for a subset of the values.

6. Select an appropriate value from the list.

7. Click OK to insert the value into the parameter field.

8. Save your changes.

3.2.4.2 Creating New Assignments for an Existing Configuration

Recall that you can make more than one assignment to a configuration. The configuration uses the same name and the same settings, but the assignment parameters are different for each instance of the configuration.

For example, suppose you create the RDC CONFIGURATION SAMPLE and define the settings for that configuration. You now want to assign that configuration of settings to JDOE, JSMITH, and all data managers. You click the New button to create a new set of assignment parameters.

For each new assignment that you create, the system inserts another instance (row) of the original configuration into the Configuration Name list and sets all the assignment parameters to the default value (that is, %). You can then change the assignment parameters for that instance.

If a configuration has multiple assignments, the configuration is listed multiple times on the RDC Configurations form. Note, however, that as you move from row to row of the same configuration, the values for the configuration settings are the same. The settings apply to the configuration. Changes you make to the settings apply to all users assigned to the configuration.

Note:
Before you can specify new assignments for an existing configuration, at least one of the assignment parameters associated with the existing configuration must be set to a non-default value (that is, cannot be set to the % sign).

To specify new assignment parameters for an existing configuration:

1. Open the RDC Administration application.

2. Select Maintain, and then select Configurations.

3. Click New to open the New Assignment Parameters dialog box.

4. Select an existing configuration for which you want to create new assignment parameters. Your new assignment parameters are in addition to any sets of parameters already defined for the configuration.

5. Click OK.

6. Click Yes. Note that the system inserts another instance of the original configuration into the Configuration Name list and sets all the assignment parameters to the default values (that is, %).

7. Modify the assignment parameters.

8. Save your changes.

3.2.5 Deleting Assignments and Configurations

When you delete a configuration, you delete one instance of the configuration and its assignments. If you made multiple assignments to the same configuration, you delete each one individually.

You cannot delete the default configuration, RDC CONFIGURATION.

To delete one instance of a configuration and its assignments:

1. Open the RDC Administration application.

2. Select Maintain, and then select Configurations.

3. Place the cursor in the row you want to delete.

4. Click Delete.

5. Click Yes to confirm the delete and automatically save your changes.

3.2.6 RDC Configurations in the Oracle Clinical Reference Local Codelists

When you create a new RDC configuration, the system also creates a new local reference codelist in Oracle Clinical. The local codelist has the following name:

RDC CONFIGURATION identifier

where identifier is the unique text string you entered in the Create New Configuration dialog box.

The local codelist has the same configuration settings as the RDC Configurations form. You can update the settings in either location.

3.3 Configuration Settings for RDC

The RDC Configurations form has many settings. This section describes only the settings applicable to RDC. See Figure 3-2.

Figure 3-2 Configuration Settings Applicable to RDC

3.3.1 Customizing the Label for the Links Section on the Home Page

The Label for the Links Tab configuration setting lets you customize the title of the Links section on the Home page. For example, you may want to change the title to More Study Information or Helpful Web Sites.

You can enter any combination of alphabetic, numeric, and special characters for the title. If you do not specify a value, RDC uses Links.

In addition, you can configure and customize the links that display in the Links section by using the Maintain Links form in the RDC Administration application. See Chapter 11, "Configuring Links" for more information.

3.3.2 Hiding the Preferences Links

The Hide the Preferences Menu configuration setting determines whether RDC displays the Preferences links in the page header and footer, and in the Data Entry window.

- Preferences link in the page header and footer. If the link is available, the user can customize the number of items to display in lists, the format of dates, and the time zone to use when displaying time stamps.

- Preferences link in the Data Entry window. If the link is available, the user can customize whether to show or hide the Save Complete prompt and the Validation Error Alert prompt.

If you set the Hide the Preferences Menu configuration setting to N, the Preferences links are available. Note that when the links are available, users can change the value you defined for the following configuration settings:

- Display in Local Time

- Prompt for Save Complete in HTML Mode

- Suppress Validation Error Alert in HTML Mode

Preferences remain in effect for the current session or until the user switches to another study. The next time the user logs in, RDC loads the assigned configuration and your defined settings. If you do not want the user to be able to change the preferences, set the Hide the Preferences Menu configuration setting to Y.

3.3.3 Displaying Time Stamps in Local Time

The Display in Local Time configuration setting affects only the display of time stamps for events such as when the CRF was last modified, verified, approved, or locked. If you set this value to Y, users see time stamps adjusted to their local time zone.

Note that this setting:

- Does not affect the format RDC uses to record time stamps in the database. RDC always stores time stamps according to the time zone of the database server.

- Does not affect the format of the time stamp entered as part of CRF data entry.

- Does not affect the format of the Last Refresh time displayed in the session information.

If the Preferences link is available in RDC, a user can open the Preferences page and then select the Display timestamps in local timezone check box to change the setting for the current session. To prevent users from setting preferences, you can hide the Preferences link. See Section 3.3.2, "Hiding the Preferences Links" for information.

3.3.4 Allowing CRF Group Actions

In RDC, the Multi Patient Casebooks page, the Single Patient Casebooks and the Review CRFs page can include several options that let the user:

- Verify a group of CRFs

- Approve a group of CRFs

- Update the custom review status for a group of CRFs

The Hide the Group Activities Menu configuration setting determines whether RDC hides or shows the group verification and approval options.

- If you set this value to Y, RDC hides the group verification and approval options.

- If you set this value to N, RDC displays the group verification and approval options.

This setting only controls the ability to verify or approve a group of CRFs (that is, the group verification and approval options). Users with the appropriate VERIFY and APPROVE privileges are still able to verify and approve an individual CRF from the Data Entry window.

For details about other options on the Group Verify and Group Approve screens, see the section "Options in Group Verify Dialog" and "Options in Group Approve Dialog" in the Oracle Clinical Administrator's Guide.

3.3.5 Using the Oracle Clinical Accessibility Rules

When a CRF becomes accessible, Oracle Clinical runs validation and derivation procedures against that CRF during batch validation or in RDC, during site validation, during patient validation, or when you save the CRF.

Ordinarily, RDC marks a CRF as accessible whenever you perform a Save Complete on the CRF.

However, if you are running a paper study or a hybrid study, you may need to apply Oracle Clinical accessibility rules. In Oracle Clinical, if a study requires Pass 2 Data Entry, Oracle Clinical does not mark the CRF as accessible until Pass 2 is complete. If a study does not require two passes, Oracle Clinical marks the CRF as accessible when Pass 1 is complete (Entry Complete).

- If Use the OC Accessibility Rules is set to N, when a CRF becomes Entry Complete, RDC marks the CRF as accessible and runs the ONLINE/DCM procedures when the CRF is saved. In addition, Oracle Clinical also processes the CRF during the next batch validation.

- If Use the OC Accessibility Rules is set to Y and the study requires two passes, RDC does not mark the CRF as accessible until the CRF reaches a status of Pass 2 Complete. As a result, the ONLINE/DCM procedures are not run until the CRF reaches a status of Pass 2 Complete.

- If Use the OC Accessibility Rules is set to Y and the study does not require two passes, the behavior is the same as if there is no accessibility setting. When a CRF becomes Entry Complete, RDC marks the CRF as accessible and runs the ONLINE/DCM procedures when the CRF is saved. In addition, Oracle Clinical also processes the CRF during the next batch validation.

3.3.6 Disabling the Save Complete Prompt

The Prompt for Save Complete in HTML Mode configuration setting lets you give users the chance to save a CRF as data complete or data incomplete.

It may be convenient to allow users to save a CRF in an incomplete status. When a CRF is saved incomplete, responses are saved to the database, but no validation procedures are executed and no prompt for change reason is issued when data is updated. Saving a CRF as incomplete implies that the user is not yet finished inputting responses and that the user intends to complete the CRF at a later time.

If Prompt for Save Complete in HTML Mode is set to Y, RDC displays a dialog box that lets the user click Save Incomplete or Save Complete to save the CRF.

If you always want CRFs to be saved in a complete status, specify N for this setting. In this case, RDC displays no prompt before saving the CRF. The user has no option to save the CRF as incomplete.

If the Preferences link is available in the Data Entry window, the user can control whether RDC prompts to save the CRF as complete or incomplete. If you do not want the user to be able to change the preferences, set the Hide the Preferences Menu configuration setting to Y. See Section 3.3.2, "Hiding the Preferences Links" for information.

3.3.7 Specifying a Default Highlighting Scheme for the Data Entry Window

In the Data Entry window, RDC uses color to highlight fields in a CRF that have discrepancies, investigators comments, an audit history, or changes since the last verification or approval.

You use the Default CRF Highlighting in HTML Mode configuration setting to specify the initial highlighting scheme for the Data Entry window.

Table 3-4 lists the valid values for the highlighting scheme. You can also position the cursor in the Value field on the RDC Configurations form, and then press F9 to select from the list of valid values.

Table 3-4 Valid Values for the Highlighting Scheme in the Data Entry Window

Value

Description

NONE

Highlights no fields.

ACTIVE_DISC

Highlights all fields that have active discrepancies.

OPEN_DISC

Highlights all fields that have an open discrepancy. Open discrepancies include active and other discrepancies.

CLOSED_DISC

Highlights all fields that have closed discrepancies. (These are manually resolved discrepancies not system closed discrepancies).

ALL_DISC

Highlights all fields that have a discrepancy.

INV

Highlights all fields that have an investigator comment.

AUDIT

Highlights all fields that have an audit history.

CHANGED_SINCE_LAST_VERIFY

Highlights all fields that have changed since the last verification. Note that fields whose only update is an update to the investigator comment are highlighted.

CHANGED_SINCE_LAST_APPROVE

Highlights all fields that have changed since the last approval. Note that fields whose only update is an update to the investigator comment are highlighted.

The user has these same options available in the Highlight field in the Data Entry window. The user can change the setting and choose to highlight different fields during a session. Once changed, the setting persists throughout the session until the user either changes the highlighting again or changes to another study. The next time the user logs in, RDC reverts to the default setting defined in the configuration.

3.3.8 Allowing Access to CRFs Entered via Oracle Clinical

The Allow HTML Data Entry for Non-migrated CRFs configuration setting affects how RDC treats CRFs that were entered via batch load operation, Oracle Clinical data entry, and you choose NOT to migrate those CRFs to DCI Forms.

- If set to N, RDC prevents users from opening and updating those non-migrated CRFs.

- If set to Y, RDC lets users open and update CRFs entered in Oracle Clinical, even if those CRFs have not been migrated to a DCI Form. (This assumes that a DCI Form exists for the DCI.)
You can control whether RDC displays a warning message when the user opens a non-migrated CRF. See Section 6.1.8, "Suppressing Prompts and Warnings" for more information.

3.3.9 Suppressing the Validation Error Alert

During data entry or data update, RDC checks the information for possible validation errors. RDC checks the data against the rules defined for the study in Oracle Clinical. For example, RDC can check if the data is the correct type (numeric, alphabetic, date), exceeds a maximum length, or matches a value in a discrete value group. If the data is incorrect, RDC displays an error message. Users have the opportunity to correct the data before continuing to the next field.

If the Suppress Validation Error Alert in HTML Mode configuration setting is set to Y, RDC does not display a message when a validation error occurs. Users can perform data entry without being interrupted by alerts when tabbing from a field where discrepant data has been entered.

Note:
When you suppress the validation error message, RDC still creates a discrepancy when the error occurs, but does not alert the user to the problem.

If the Preferences link is available in the Data Entry window, the user can control whether RDC shows or hides the validation alert. If you do not want the user to be able to change the preferences, set the Hide the Preferences Menu configuration setting to Y. See Section 3.3.2, "Hiding the Preferences Links" for information.

3.4 Required Parameters in an rdcConfig.properties File

The rdcConfig.properties file contains global parameters for the RDC application and their attributed values. There are a number of properties that are required to be included in the rdcConfig.properties file and, of these properties, some may be edited to customize RDC.

A typical properties file in RDC should contain the parameters described in Table 3-5. The default values indicated are those set by the installer.

Table 3-5 Typical Parameters in an rdcConfig.properties File

Property

Mandatory?

Default value

Description

application_path

Yes

C:\opapps52

The path for the home folder of the application, OPA_HOME.

This folder stores the bin folder with DCAPI DLL files and where the system creates the data entry log files if debugging is enabled.

dataentry_cache_disk_path

Yes

C:\opapps52\rdc

The location where data entry cache files are stored, if applicable.

dataentry_cache_disk_size

No

Blank

The maximum disk space allocated for data entry.

dataentry_cache_distribute

No

Blank

performanceprofile

No

Blank

If the value is set to 1, performance profiling for data entry sever code is enabled.

xhrdtime

No

Blank

Attribute for storing the XHRD time value used by the JavaScript client.

dataentry_service_request_timeout

No

6000

The number of seconds after which data entry commands time out.

dataentry_reportlog_path

Yes

C:\opapps52\rdc\rlogs

The path where the data entry report is stored.

dataentry_log_path

Yes

C:\opapps52\rdc\logs

The path where the data entry log is stored.

If the application_path is set, then this path is not used and the log folder is created inside the home folder.

dataentry_temp_path

Yes

C:\opapps52\rdc\temp

The path where temporary data entry files are stored.

rw_webservice_url

No

http://host-domain/reports/rwwebservice

The URL of the report server web service, of the form host.domain:port.

web_server_url

No

Blank

The URL of the web server for CRF help.

max_row_fetched

No

1000

The maximum number of rows that can be fetched from the database for one query.

rdc_session_timeout

No

30

The number of minutes after which requests are timed out.

jdbc_ds_name

No

jdbc/dbnameDS

The default JNDI name of the data source to which RDC connects.

crf_images_path

No

C:\opapps52\html\rdc\dcif_images

The location where external images used for CRFs are stored.

development_mode

Yes

0

Do not change this value.

To edit the properties file:

1. Navigate to the OPA_CONFIG_FOLDER as specified in the opa52 registry under HKEY_LOCAL_MACHINE > Software > Oracle.

2. Back up the rdcConfig.properties file.

3. Open the rdcConfig.properties file in a text editor.

4. Make changes as necessary.

Tip:
Do not use the Tab key while editing the file, use the space bar instead. Also, do not enter extra spaces either for parameters or values. Make sure that no trailing space is left for any parameter values unless otherwise required.

5. Save the file.

6. Restart the OPA server for the changes to take effect. See "Restarting the OPA Server" for instructions.

4 Configuring Discrepancy Management

A discrepancy is any data that falls outside of an expected range of values or is otherwise flagged during the edit check process as an error. Examples of a discrepancy are an invalid date, an age greater than the maximum age for the study, and inconsistent information across CRFs.

Discrepancy management is the process that systematically addresses discrepancies generated within a study. For each discrepancy assigned to a user role, a user must identify the cause, assess the error, and determine the appropriate action. The user can choose to resolve the discrepancy or route it to another user. Correcting and managing discrepancies ensures that the data is complete, accurate, and compliant with the study protocol.

Using Oracle Clinical, you configure several features that help users manage discrepancies while entering and modifying data in the RDC application.

This chapter includes the following topics:

- Tools for Configuring Discrepancy Management

- Defining the Reasons for Discrepancies

- Defining the Review Statuses for Discrepancies

- Configuring the Access Statuses for Discrepancies

- Configuring the Actions Allowed against Discrepancies

- Defining the Resolution Reasons for Discrepancies

- Preventing Update to OTHER Discrepancies

4.1 Tools for Configuring Discrepancy Management

You use the reference codelists in Oracle Clinical to define your discrepancy management system for both Oracle Clinical and RDC.

To configure most settings for discrepancy management, you use the installation reference codelists in Oracle Clinical. The settings in the installation reference codelists apply to your entire installation.

To access the installation reference codelists:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Installation Codelists.

This chapter assumes you are familiar with querying, modifying, and saving reference codelists. If you need more information on reference codelists, see the Oracle Clinical Administrator's Guide.

4.2 Defining the Reasons for Discrepancies

A reason provides an explanation of why the discrepancy exists. You can define the reasons for:

- Manual discrepancies

- Univariate discrepancies

- Multivariate discrepancies

In RDC, users with the proper privileges can add a manual discrepancy to a CRF. In the Add Discrepancy dialog box, users must select a reason from the drop-down list that explains why they are adding the discrepancy. You use the MANUAL SOURCE TYPE CODE reference codelist to define these reasons.

For system-generated univariate discrepancies, RDC automatically fills in the Reason field based on the type of discrepancy. You define these reasons in the Standard Text Maintenance form.

For system-generated multivariate discrepancies, RDC does not display the reason. You can, however, customize the reasons for use in Oracle Clinical, which does display the reason for a multivariate discrepancy.

Note:
The Maintain Discrepancy Database form in Oracle Clinical labels the Reason as Category.

4.2.1 Defining the Reasons for Manual Discrepancies

In RDC, a user can add the following types of manual discrepancies:

- Field discrepancy

- Section discrepancy

When a user adds a manual discrepancy to a CRF, RDC displays the Add Discrepancy dialog box. The user must select a reason for the discrepancy from the list in the Reason field. Optionally, the user can enter additional comments about the discrepancy.

To define the list of reasons for a manual discrepancy, you modify the MANUAL SOURCE TYPE CODE reference codelist in Oracle Clinical. (See Figure 4-1.) For each reason, you enter values into the Short Value field and the Description field.

RDC displays the text you enter in the Description field as the list of reasons that the user can select from when adding a manual discrepancy. Oracle Clinical stores the short value in the database.

The first time the user adds a manual discrepancy during a login session, RDC automatically displays the default reason in the Reason field. The user can select a different reason from the drop-down list. For subsequent manual discrepancies added by the user, RDC displays the last reason the user selected. The user can always select a different reason.

Figure 4-1 Defining the Reasons for a Manual Discrepancy

4.2.2 Defining the Reasons for Univariate Discrepancies

When a univariate discrepancy is raised, RDC automatically determines which reason to use based on the type of univariate discrepancy. Examples of reasons for univariate discrepancies are DATA TYPE, LENGTH, and MANDATORY.

To define the reasons for univariate discrepancies:

1. Open Oracle Clinical.

2. Navigate to Admin, Discrepancy Mgmt Admin, and then select Standard Text Maintenance. See Figure 4-2.

Figure 4-2 Defining the Reasons for Univariate Discrepancies

You use the fields in the Standard Text Maintenance form to describe each type of univariate discrepancy as follows:

- Text Type — Select COMMENT to indicate that this row defines one description for a univariate discrepancy.

- Sub Type — Select from the list of valid types of univariate discrepancies.

- Standard Text Name — Ordinarily, you specify a name to match the Sub Type. However, if you want to specify more than one reason for a discrepancy type, use this field to specify a unique identifier.

- Default — If you specify more than one reason for a certain type of discrepancy, select which reason is the default value. RDC uses the default value the first time a discrepancy of that type is raised. The user can always select one of the alternative reasons provided.

- Standard Text — Specify the description that you want RDC to display for the discrepancy type raised. Note that you can use variables to include the data value of the discrepant response as well as the definitional components of the question.

See the Oracle Clinical Administrator's Guide for details on creating default standard text depending on the type of univariate discrepancy.

4.2.3 Defining the Reasons for Multivariate Discrepancies

Oracle Clinical raises multivariate discrepancies in RDC when Oracle Clinical executes its defined validation procedures. Although you can customize the reason for a multivariate discrepancy, RDC does not display the reason for a multivariate discrepancy.

However, Oracle Clinical does display the reason. For details on how to create and modify procedures to customize the reason description for multivariate discrepancies, see Oracle Clinical Conducting a Study.

4.3 Defining the Review Statuses for Discrepancies

When a user takes action on a discrepancy, the discrepancy goes to a new review status. For system-generated discrepancies (univariate and multivariate), the system assigns the default review status. For manual discrepancies, the user selects the review status.

One task you perform in configuring your discrepancy management system is to map an action to a resultant review status. You use the DISCREPANCY REV STATUS CODE installation codelist to define all the discrepancy review statuses possible to use in your discrepancy management workflow.

Both the RDC and the Oracle Clinical discrepancy management systems use the DISCREPANCY REV STATUS CODE codelist.

RDC uses the text string in the Description field to display the status of a discrepancy in any discrepancy management-related window, form, page, or report. Oracle Clinical uses the text string in the Short Value field to display the status of a discrepancy.

4.3.1 Default Entries for the DISCREPANCY REV STATUS CODE Codelist

Table 4-1 lists the entries in the DISCREPANCY REV STATUS CODE installation codelist following the initial installation of Oracle Clinical.

Table 4-1 Default Entries for the DISCREPANCY REV STATUS CODE Codelist

Short Value

Long Value

Description

CLOSED

CLOSED

The system sets a discrepancy's status to Closed when it is resolved by either updating the data to a nondiscrepant value or changing the validation procedure or question attribute in such a way that the existing data is no longer discrepant. The discrepancy's system status changes to Obsolete and the discrepancy is removed from its DCF (if any) and no longer appears as current in discrepancy reports.

CRA REVIEW

Null

Under CRA Review

INV REVIEW

Null

Under Investigator Review

RESOLVED

IRRESOLVABLE

Not assigned to any person or process. Setting a discrepancy's status to RESOLVED does not cause the system to close the discrepancy. That happens only when the data is no longer discrepant, either because the data has been updated to a nondiscrepant value or because the validation procedure or question attribute that flagged the value as discrepant has been changed in such a way that the existing value is no longer considered discrepant.

IRRESOLVABLE

IRRESOLVABLE

Irresolvable
(That is, closed. Cannot be resolved.)

TMS EVALUATION

TMS EVALUATION

TMS Evaluation

UNREVIEWED

Null

Not yet reviewed

TMS IN PROGRESS

TMS IN PROGRESS

TMS in Progress - Set/Reset by system

DM REVIEW

Null

Under DM Review

INT DM REV

Null

Internal - Under DM Review

INT CRA REV

Null

Internal - Under CRA Review

4.3.2 Rules for the DISCREPANCY REV STATUS CODE Codelist

When entering and modifying values in the DISCREPANCY REV STATUS CODE reference codelist, you must follow these rules:

- The codelist must contain at least one short value entry with a long value of IRRESOLVABLE, which indicates that a user must specify a resolution reason when setting a discrepancy to this status. By default, the codelist contains the short values RESOLVED and IRRESOLVABLE, which are each assigned the long value IRRESOLVABLE.

- The codelist must contain a short value entry of UNREVIEWED. The Active check box corresponding to the value must always be selected. The UNREVIEWED value is the system-coded default status of any newly created discrepancy, except multivariate discrepancies. For multivariate discrepancies, the initial review status is defined in the Details block of the Oracle Clinical validation procedure that generates the discrepancy.

- The Active check box must be selected for each review status that you want to allow for a certain user role. In other words, if you set an entry in a DISCREPANCY STATUS role codelist to active, then you must also set the corresponding entry in the DISCREPANCY REV STATUS CODE codelist to active.
Conversely, if you set an entry in the DISCREPANCY REV STATUS CODE codelist to inactive, you must also set the corresponding entry in each DISCREPANCY STATUS role codelist to inactive. If not, users receive an error message that problems exist with the discrepancy management system.

4.4 Configuring the Access Statuses for Discrepancies

RDC uses the access status to control whether a user can take action against a discrepancy.

When Oracle Clinical is installed, the system automatically creates the following DISCREPANCY STATUS role codelists, where role specifies one of the default user roles:

- DISCREPANCY STATUS CRA

- DISCREPANCY STATUS DM

- DISCREPANCY STATUS INV

- DISCREPANCY STATUS SITE

Only RDC uses the set of DISCREPANCY STATUS role codelists. Each codelist is specific to a user role.

In addition, each codelist maps the Oracle Clinical discrepancy review statuses to the RDC discrepancy access statuses appropriate to the user role. RDC uses the codelist to determine the access status of the discrepancies for a user based on the user's role.

4.4.1 Access Status Values

In each DISCREPANCY STATUS role codelist, the short value defines the discrepancy review status. Recall that every short value in each DISCREPANCY STATUS role codelist must also appear in the DISCREPANCY REV STATUS CODE codelist.

The long value defines the discrepancy access status. The access status determines whether users in a certain role can take action on a discrepancy.

Long values must be in uppercase. Acceptable values for the long value are:

- ACTIVE — The current user can take action against this discrepancy.

- OTHER — The discrepancy requires the attention of a different user role. You can prevent users from taking action on OTHER discrepancies. See Section 4.7, "Preventing Update to OTHER Discrepancies" for more information.

- HIDDEN — The current user cannot view or take action against this discrepancy.
This functionality is intended only for section-type discrepancies. At run time, if the user selects a univariate or multivariate discrepancy, the Action drop-down list excludes any action that would route the discrepancy to a status that is HIDDEN for any role.

Note:
If you change the long value to HIDDEN for a status that has already been applied to univariate or other types of discrepancies, these existing discrepancies are hidden to users with the relevant role, even though only section discrepancies are intended to allow hiding.

- CLOSED — If the discrepancy was manually closed by a user, any user with UPDATE or UPD_DISCREP privilege can re-open the discrepancy. System-closed discrepancies cannot be re-opened.

Note that the discrepancy access status does not determine what functions a user can perform on the discrepancy or the patient data. The DISCREPANCY ACTIONS role codelists determine what routing and resolution actions each user role can take on a discrepancy.

4.4.2 Colors Used to Indicate Discrepancy Access Status

Table 4-2 describes the colors that RDC uses to indicate the status of the discrepancies, if any, in a CRF. RDC uses these colors to highlight the patient icon, the CRF icon, and the individual fields in a CRF.

Note that:

- HIDDEN discrepancies are not highlighted in any color because they are not visible to particular user roles.

- RDC uses green to highlight the fields in a CRF that have a discrepancy that was manually closed by the user. Fields with a system-closed discrepancy are not highlighted.

Table 4-2 Colors Used to Indicate Discrepancy Access Status

Color

Access Status

Implication

Red

ACTIVE

The CRF contains at least one open discrepancy that requires attention by the user role to which the current user is assigned.

Yellow

OTHER

The CRF contains only open discrepancies that require the attention of a user role different from the one to which the current user is assigned.

White

CLOSED

The CRF contains no visible open discrepancies. Three conditions may be true for a white CRF or patient icon:

- The CRF may contain discrepancies that are hidden from the current user's user role.

- The CRF may have contained discrepancies at one time, but all discrepancies are closed or obsolete.

- The CRF never had any discrepancies.

4.4.3 Default Entries for the DISCREPANCY STATUS role Codelists

The access status depends upon the current user's user role and upon how you configure each review status to appear to that user role. For example, a discrepancy with a review status of Under CRA Review should appear as ACTIVE to a CRA, but as OTHER to an investigator.

Table 4-3 lists the entries for the DISCREPANCY STATUS role codelists for the default user roles.

If you combine the information in Table 4-2 and Table 4-3, you can find how a user assigned the DM role sees a discrepancy of review status DM REVIEW with a red highlight (ACTIVE), while a user assigned the SITE role sees the same discrepancy with a yellow highlight (OTHER).

Table 4-3 User Roles and the Default RDC Discrepancy Access Statuses

Short Value – Oracle Clinical Discrepancy Review Status

Long Value – RDC Discrepancy Access Status

CRA

DM

INV

SITE

UNREVIEWED

ACTIVE

ACTIVE

ACTIVE

ACTIVE

CRA REVIEW

ACTIVE

OTHER

OTHER

OTHER

INV REVIEW

OTHER

OTHER

ACTIVE

OTHER

DM REVIEW

OTHER

ACTIVE

OTHER

OTHER

TMS EVALUATION

OTHER

OTHER

OTHER

OTHER

TMS IN PROGRESS

OTHER

OTHER

OTHER

OTHER

RESOLVED

CLOSED

CLOSED

CLOSED

CLOSED

IRRESOLVABLE

CLOSED

CLOSED

CLOSED

CLOSED

CLOSED

CLOSED

CLOSED

CLOSED

CLOSED

INT CRA REV

ACTIVE

OTHER

HIDDEN

HIDDEN

INT DM REV

OTHER

ACTIVE

HIDDEN

HIDDEN

INT RESOLVED

CLOSED

N/A

CLOSED

CLOSED

4.4.4 Rules for the DISCREPANCY STATUS role Codelist

When entering and modifying values in a DISCREPANCY STATUS role codelist, you must follow these rules:

- Each DISCREPANCY STATUS role codelist must include all short values that appear in the DISCREPANCY REV STATUS CODE codelist, and must not contain any values not in that codelist. When you add a short value to one codelist, you must add the same short value to the other codelist. (An exception is the CLOSED status, described below).
You then use the Active check box to enable and disable the review status for a user role.

- Each codelist must contain the short value CLOSED, which has a corresponding long value CLOSED. This is the status that is used for any system-resolved discrepancy, that is, a data discrepancy that was resolved as the result of an update to a non-discrepant value.

- The RESOLVED and IRRESOLVABLE short values must have a long value of CLOSED for all roles.

- If a review status is CLOSED for one user role it must be either CLOSED or HIDDEN for all other user roles. Note also that for any review status that appears as CLOSED in a DISCREPANCY STATUS role codelist, the DISCREPANCY REV STATUS CODE codelist must represent the review status with a long value of IRRESOLVABLE.

- The setting of the Active check box determines whether discrepancies of that status are visible to users with the relevant role. If the Active check box is not selected, users with the role cannot see discrepancies of that status. If the Active check box is selected, users with the role can see discrepancies of that status. The way discrepant values are displayed depends on the long value.

Note:
Either disabling the Active check box or setting the long value to HIDDEN has the effect of hiding discrepancies of the relevant status from users with the relevant role. However, to ensure compatibility with future releases and to avoid confusion between the two settings, Oracle recommends that you use the Active check box to hide discrepancies. In addition, the Active check box lets you hide all types of discrepancies (section, manual field, univariate, or multivariate). The HIDDEN value lets you hide section discrepancies only.

- If an entry in a DISCREPANCY STATUS role codelist is active, then the corresponding entry in the DISCREPANCY REV STATUS CODE codelist must also be active. If not, the discrepancy configuration is invalid. RDC will display an error message to alert users to the problem.

- The Description field is optional for all entries.

- The setting of the Default check box has no effect. The default status of a new discrepancy is always UNREVIEWED.

4.5 Configuring the Actions Allowed against Discrepancies

In RDC, a user changes the review status of a discrepancy by selecting an option from the list in the Action field. You use the DISCREPANCY ACTIONS role codelists to define the set of routing and resolution actions that each user role can take against discrepancies.

When Oracle Clinical is installed, the system automatically creates the following DISCREPANCY ACTIONS role codelists, where role specifies one of the default user roles:

- DISCREPANCY ACTIONS CRA

- DISCREPANCY ACTIONS DM

- DISCREPANCY ACTIONS INV

- DISCREPANCY ACTIONS SITE

Only RDC uses the set of DISCREPANCY ACTIONS role codelists. Each codelist is specific to a user role.

In the Short Value field, you enter the name of the discrepancy review status for which users of the relevant role can take action on the discrepancies. The status you specify must be listed in the DISCREPANCY REV STATUS CODE codelist.

In the Long Value field, you enter the text that RDC displays in the Action drop-down list. You use the Active check box to enable the action.

Note:
At run time, if the user selects a univariate or multivariate discrepancy, the Action drop-down list excludes any action that would route the discrepancy to a status that is HIDDEN (that is, has a long value of HIDDEN in the DISCREPANCY STATUS role codelist) for any role.

4.5.1 Default Entries for the DISCREPANCY ACTIONS role Codelists

Table 4-4 lists the default entries for the DISCREPANCY ACTIONS DM codelist, which defines the allowed actions for the Data Manager (DM) user role.

Table 4-4 Default Entries for the DISCREPANCY ACTIONS DM Codelist

Short Value (Resulting Review Status)

Long Value
(Action)

INV REVIEW

Send to site

TMS EVALUATION

Send for classification

RESOLVED

Close - resolved

IRRESOLVABLE

Closed - no resolution

INT CRA REV

Internal CRA Review

4.5.2 Rules for the DISCREPANCY ACTIONS role Codelist

When entering and modifying values in a DISCREPANCY ACTIONS role reference codelist, you must follow these rules:

- Each DISCREPANCY ACTIONS role codelist must contain a subset of the short values (the statuses) defined in the DISCREPANCY REV STATUS CODE codelist. The long value specifies an action that the user can take against a discrepancy. The corresponding short value, which must match a short value in the DISCREPANCY REV STATUS CODE codelist, identifies the status RDC assigns to the discrepancy when the user selects the action.

- CLOSED should not appear as a short value in any DISCREPANCY ACTIONS role codelist.

- You must specify text in the Long Value field. RDC displays this text in the Action drop-down list.

- The Description field is optional for all entries.

4.6 Defining the Resolution Reasons for Discrepancies

In RDC, users can manually resolve discrepancies. When doing so, the user must also provide an explanation — a reason — for resolving the discrepancy. The user must select a resolution reason from the list that you define.

To define the possible set of resolution reasons, you use the DISCREPANCY RESOLU TYPE CODE installation reference codelist.

You enter information into the Description field and the Short Value field. RDC uses the text string that you specify in the Description field to display the list of resolution reasons to the user. Oracle Clinical stores the corresponding short value in the database.

Note:
RDC reserves the CND BLK DELETED value as the resolution for a manual discrepancy associated with a conditional block that was deleted. The value is hard-coded. Do not add or use this value in the DISCREPANCY RESOLU TYPE CODE codelist.

Table 4-5 lists the entries in the DISCREPANCY RESOLU TYPE CODE codelist following the initial installation of Oracle Clinical.

Table 4-5 Values for the DISCREPANCY RESOLU TYPE CODE

Short Value

Long Value

Description

CRA VERIFY

CONFIRMED

CRA Correction

CRA VERIFY-INV

CONFIRMED

CRA Correction, Investigator consulted

CRA VERIFY-SRC

CONFIRMED

CRA Correction, Source Data consulted

INV VERIFY

CONFIRMED

Investigator Correction

STUDY ASSUMP

CONFIRMED

Study Assumption

NO ACTION REQD

CONFIRMED

No Action Required

ELIMINATED

SUPERSEDED

Data value changed. Disc no longer applicable.

OVERRULED

NON DISCREPANT

Disc not considered a validation error.

DATA MODIFIED

SUPERSEDED

Data value changed. Disc no longer applicable.

INV-NO INFO

IRRESOLVEABLE

Investigator queried. No further information available.

4.7 Preventing Update to OTHER Discrepancies

Only RDC uses the DISCREPANCY NO OTHER UPDATE installation codelist.

You can use the DISCREPANCY NO OTHER UPDATE codelist to specify which user roles do not have access to and cannot update discrepancies that appear to them with a status of OTHER.

By default, the DISCREPANCY NO OTHER UPDATE codelist has no values. All users can update discrepancies with a status of OTHER. To prevent users from updating OTHER discrepancies, you add one or more user roles to the codelist.

To prevent users with a particular role from updating OTHER discrepancies:

1. Open the DISCREPANCY NO OTHER UPDATE codelist.

2. Enter the role name in the Short Value field. The value you enter must be exactly the same as one of the long values in the USER GROUP ROLES reference codelist. For example, CRA, INV, or SITE.

Caution:
The system does not check the validity of your entries. You must be careful to specify only valid user roles. If the values do not match exactly, users with the role will still be able to update OTHER discrepancies.

3. Select the Active check box. An active entry indicates the user role cannot update OTHER discrepancies.

4. Save your changes.

The Seq, Long Value, Default, and Description fields are not used by RDC.

You can grant this privilege to any number of roles.

To allow the update of OTHER discrepancies for a role that you added to the DISCREPANCY NO OTHER UPDATE codelist, you can either:

- Delete the record by using the command on the Data menu.

- Make the value inactive by clearing its Active check box.

5 Configuring Custom Review Types

To facilitate centralized monitoring in RDC, you can create custom review types, which are similar to the predefined Verify and Approve review types. By defining custom review types, you enable and can track reviews performed by users with a specific role, such as data manager, safety expert, or adjudicator.

You specify default custom review requirements at the installation, study, or DCI level, which can require that all, none, or some custom review types be performed on CRFs. You can define custom review types in the CUSTOM REVIEW TYPES installation codelist in Oracle Clinical together with a privilege for each, and then assign each privilege to the appropriate reviewer.

This chapter includes the following topics:

- Section 5.1, "Review Statuses for Custom Review Types"

- Section 5.2, "Define Custom Review Type Requirements"

- Section 5.3, "Finding CRFs with the Review Not Required (RN) Status Set by Users"

- Section 5.4, "Viewing Audit History for Changes in Custom Review Requirements"

- Section 5.5, "Add Custom Review Types"

- Section 5.6, "Assign Custom Review Type Privileges to Users"

- Section 5.7, "Define Custom Review Type Activities"

5.1 Review Statuses for Custom Review Types

Each review type you define can have four possible review statuses assigned to CRFs:

- Review Required

- Review Not Required

- Awaiting Re-review

- Review Complete

CRF icons also display a review status indicator. See the section "Custom Review Status Icons" in Appendix A of the Oracle Clinical Remote Data Capture Classic Data Entry User's Guide.

5.2 Define Custom Review Type Requirements

You can define a default requirement for custom reviews at the installation, study, GLIB DCI, and study DCI level. The multi-level requirements can specify that all, none, or some custom review types are required by default for CRFs at a particular level. The default applies to entered CRFs with no explicitly set review status.

After you define custom review requirements, RDC users can search for CRFs requiring review and can see indicators on the CRF icon for the review status of CRFs; see Review Statuses for Custom Review Types.

5.2.1 Set Custom Review Requirement for the Installation

The installation-wide requirement applies for all entered CRFs that do not have a review status that was explicitly set by a user.

1. Log in to Oracle Clinical as an administrator.

2. Navigate to Admin and then DCI Form Local Database Settings.

3. At the bottom, expand the Default DCI Custom Review Requirements option by clicking the plus sign.

4. For the setting Allow CRF status change to RN when review is required?, specify Y or N in the Value column.
A value of Y allows reviewers to change the CRF review status to Review not Required even when the installation setting, which you set in the next step, is set to require custom reviews.

5. For the setting Custom Reviews are Required, specify Y or N in the Value column.
A value of Y requires that all custom review types be performed for all CRFs.

6. Click Save.

5.2.2 Set the Custom CRF Review Requirement for a Study

You can set specific custom review requirements for CRFs in a study that are different the installation-wide requirement for a particular study. This requirement applies for all entered CRFs in the study that do not have a review status that was explicitly set by a user.

1. Log in to Oracle Clinical as an administrator.

2. Expand the Design node and select DCI Form Local Study Settings.

3. Select the study or switch to the study for which you want to set the requirement.

4. At the bottom, expand the Default DCI Custom Review Requirements group of settings by clicking the plus icon to its left.

5. For the setting Allow CRF status change to RN when review is required?, specify Y or N in the Value column.
A value of Y allows reviewers to change the CRF review status to Review not Required even when the study setting, which you set in the next step, is set to require custom reviews.

6. For the setting Custom Reviews are Required, specify Y or N in the Value column.
A value of Y requires that all custom review types be performed for all CRFs in a study.

7. Click Save.

Note:
If you specify custom review requirements for a study DCI, updates to the study-level custom review requirements will not override the study DCI. If you want to enforce the study-level requirement in such a DCI, you have to manually change the study DCI custom review requirements. See Set Custom Review Requirement for a Study DCI for instructions.

Enforce the Installation-wide Custom Review Requirement for CRFs in a Study

If a study has a custom review requirement defined, the installation-wide default is not enforced for that study. You can apply the installation default to clear the user-defined requirement for the study.

1. Log in to Oracle Clinical as an administrator.

2. Expand the Design node and select DCI Form Local Study Settings.

3. Select the study or switch to the study for which you want to edit the requirement.

4. At the bottom, expand the Default DCI Custom Review Requirements group of settings by clicking the plus icon to its left.

5. For the setting Allow CRF status change to RN when review is required?, select the checkbox Inherit From Local DB Setting. The column Local DB Value shows the inherited value.

6. For the setting Custom Reviews are Required, select the checkbox Inherit From Local DB Setting. The column Local DB Value shows the inherited value.

7. Click Save.

5.2.3 Set Custom Review Requirement for a GLIB DCI

You can set a different custom review requirement than the default that is defined at the installation or study level, which may require all or none of the available review types for all CRFs. At the individual DCI level, you can refine the requirement by setting all, none, or only some custom review types to be required for CRFs of the DCI. This requirement applies for all entered CRFs of the DCI that do not have a review status that was explicitly set by a user.

1. Log in to Oracle Clinical as a user with privileges to work in the Glib subsystem.

2. Expand the Glib node, then expand DCIs DCMs Procedures, and then select DCIs.

3. Select the Review Requirements tab.

Tip:
The checkbox Allow CRF status change to RN when review is required? at the top of the tab is read-only and indicates the inherited installation setting. You can specify a different setting for individual custom review types in step 7.

4. Query in the DCI Name field for the DCI for which you want to set the custom review requirements.

5. Click in the Custom Reviews Required field for that DCI to open the Reviews Required dialog box.

6. Select (highlight) all the review types that should be required for CRFs in this DCI.

Tip:
Clicking a single review type drops the current selection and selects only that review type. Use Shift+click, Ctrl+click, or the controls below the list to select or deselect multiple review types.

7. Make sure that Allow Override RN Status is checked for only those selected (required) review types for which you want to allow reviewers to set the review status to Review not Required (RN).

8. Click Save.

5.2.4 Set Custom Review Requirement for a Study DCI

You can set a different custom review requirement than the default that is defined for the installation or study DCI. This requirement applies to all entered CRFs in the study DCI that do not have a review status that was explicitly set by a user.

Tip:
You can specify custom review requirements for any DCI, whether active, provisional, or retired. You may want to define requirements even for a retired DCI in case a CRF, entered against the retired DCI, is updated.

1. Log in to Oracle Clinical as a user with privileges to work in the Definition subsystem.

2. Expand the Definition node, then expand DCIs, and then select DCIs.

3. Select or switch to the study to which the DCI belongs.

4. Select the Review Requirements tab.

Tip:
The checkbox Allow CRF status change to RN when review is required? at the top of the tab is read-only and indicates the inherited installation or study setting, if one is defined. You can specify a different setting for individual custom review types in step 7.

5. Query in the DCI Name field for the DCI for which you want to set the custom review requirements.

6. Click in the Custom Reviews Required field for that DCI to open the Reviews Required dialog box.

7. Select (highlight) all the review types that should be required for this DCI.

Tip:
Clicking a single review type drops the current selection and selects only that review type. Use Shift+click, Ctrl+click, or the controls below the list to select or deselect multiple review types.

8. Make sure that Allow Override RN Status is checked for only those selected (required) review types for which you want to allow reviewers to set the review status to Review not Required (RN).

9. Click Save.

5.3 Finding CRFs with the Review Not Required (RN) Status Set by Users

CRFs for which the review status has been set to Review not Required by users are not affected by changes in the custom review requirements, defined in Oracle Clinical. To find such CRFs and determine if they would require review based on the new requirements you can use:

- The option Explicitly set RN status from the Review Status filter in the Search pane.

- The metrics for Explicitly set RN status in the Patient Summary, Study Site Summary, or Single Patient Casebooks page.

5.4 Viewing Audit History for Changes in Custom Review Requirements

While it is possible to review audit history for those cases where a user explicitly changes the review status of a CRF, the status of a CRF may also change as a result of changes in Custom Review Requirements at the DCI level will appear in the review status history. Only changes at the installation or study level will not appear in the review status history.

To view audit history for changes in the Custom Review requirements, you can query the columns crt_list and allow_crt_rn in the DCIS and DCIS$JN tables. For details about these columns, see the Oracle Clinical Stable Interface Technical Reference Manual.

Example 5-1 Query to find DCIs for which the CRT requirement has changed

column dci_id format 999999999
column allow_crt_rn format a10
column crt_list format a30
set pages 1
set lines 200
select before.dci_id, before.allow_crt_rn, after.allow_crt_rn
from (select row_number () over (order by JN_TIMESTAMP) r_num, dci_id, allow_crt_rn from dcis$jn) before
join (select row_number () over (order by JN_TIMESTAMP) r_num, dci_id, allow_crt_rn from dcis$jn) after
on before.R_NUM = after.R_NUM+1
where before.dci_id = after.dci_id
and before.allow_crt_rn != after.allow_crt_rn;

select before.dci_id, before.crt_list, after.crt_list
from (select row_number () over (order by JN_TIMESTAMP) r_num, dci_id, crt_list from dcis$jn) before
join (select row_number () over (order by JN_TIMESTAMP) r_num, dci_id, crt_list from dcis$jn) after
on before.R_NUM = after.R_NUM+1
where before.dci_id = after.dci_id
and before.crt_list != after.crt_list;

5.5 Add Custom Review Types

You create custom review types and their corresponding privileges in the CUSTOM REVIEW TYPES installation codelist in Oracle Clinical. This codelist comprises all user-defined review types and the privilege required for each of the review types.

You can define up to 444 custom review types for a DCI.

1. Log in to Oracle Clinical as an administrator.

2. Navigate to Admin, Reference Codelists, and select Installation Codelists.

3. In the Maintain Installation Codelist window, query for the CUSTOM REVIEW TYPES codelist.

4. In the Reference Codelist Values section, fill in the Long Value field with a name for the new custom review type, such as SAFETY_REVIEW or DM_REVIEW.

5. Fill in the Short Value field with a name for the privilege required to perform that type of review, such as SAFEREV or DMREV.

Note:
The Short Value field accepts up to 8 characters.

6. To activate the custom review type, select the Active checkbox.

7. Optionally, you can store details about the custom review type in the Description field.

8. Repeat steps 4 through 7 to add more custom review types, as necessary.

9. Click Save after you have finished defining custom review types.

5.5.1 Deactivate Custom Review Types

If you deactivate a custom review type from the CUSTOM REVIEW TYPES reference codelist in Oracle Clinical, the change takes effect as follows:

- In RDC, the inactive custom review type is available for search but with suffix (inactive). However, the calculation of the CRT icon will not consider the inactive custom review type.

- In RDC Data Entry window, reviewers with privileges for the inactive custom review type and one or more active custom review types (so that they can still change review statuses) can view audit history for the inactive custom review type, which appears prefixed by (inactive).

1. Log in to Oracle Clinical as an administrator.

2. Navigate to Admin, Reference Codelists, and select Installation Codelists.

3. In the Maintain Installation Codelist window, query for the CUSTOM REVIEW TYPES codelist.

4. Under Reference Codelist Values, find the review type that you want to retire and deselect the Active checkbox.

5. Click Save.

6. If the custom review type is explicitly required based on the study DCI or GLIB DCI review requirement, the study manager or global librarian must also access the Maintain Study DCIs or Maintain GLIB DCIs form, respectively, at which point the inactive custom review type is removed, and then save changes. If this was the only custom review type that was required for the DCI, the DCI then inherits the study or installation default requirement, as applicable.

5.6 Assign Custom Review Type Privileges to Users

A CRF has multiple review statuses at any given time, one for each custom review type. The current review status for a custom review type (see Review Statuses for Custom Review Types) and the corresponding review status indicator on the CRF icon are visible to users who have the privilege for that review type. You define the privilege together with the custom review type; for details, see Add Custom Review Types.

For example, having the custom review types SAFETY_REVIEW and DM_REVIEW, if safety review is complete and DM review is not complete for a CRF, the same CRF appears as having the review status Review Complete (RC on the CRF icon) to users with the privilege for SAFETY_REVIEW, and it appears with the status Review Required (RQ on the CRF icon) to users who have the privilege for DM_REVIEW.

You can assign privileges from Study Security or Site Security in the RDC Administration Tool. See "Assigning Study and Site Security Privileges" for instructions.

You can also assign privileges from Oracle Clinical. See the Oracle Clinical Administrator's Guide for details.

5.7 Define Custom Review Type Activities

You can leverage custom review types by including them in custom activities. Using the REVIEW_TYPE and REVIEW_STATUS parameters of the rdc_zf_surround_activitiy.setSearchCondition procedure, you can create or edit a procedural activity to search by custom review values. See "Creating and Maintaining Customized Activities" for instructions.

For more information, see:

- ”Performing Custom Reviews” in the Oracle Clinical Remote Data Capture User's Guide

- "Securing Remote Data Capture"

6 Customizing Data Entry Behavior

You can customize the behavior of data entry in RDC by modifying the DCI Form Runtime settings and several reference codelists in Oracle Clinical.

This chapter assumes you are familiar with modifying forms and reference codelists in Oracle Clinical. For general information about how to modify forms and reference codelists, see the Oracle Clinical Administrator's Guide.

This chapter includes the following topics:

- Configuring the DCI Form Runtime Settings

- Enabling HTML Data Entry for RDC

- Displaying the Visit-Owning Interval on the Casebooks Page

- Allowing Investigator Comments

- Adding a Customized Reference Field to the Search Pane

- Controlling the Display of Conditional Blocks within a CRF

- Suppressing Prompts and Warnings

- Using DCI Book Assignment

- Specifying CRFs for Single Use

- Customizing the Display of a List of Values

- Defining the List of Allowable Change Reasons

- Setting the Format of Dates

6.1 Configuring the DCI Form Runtime Settings

The DCI Form Runtime settings let you customize the RDC application, including the following options:

- Enabling HTML Data Entry for RDC

- Displaying the Visit-Owning Interval on the Casebooks Page

- Allowing Investigator Comments

- Adding a Customized Reference Field to the Search Pane

- Controlling the Display of Conditional Blocks within a CRF

- Suppressing Prompts and Warnings

In Oracle Clinical, you can configure the DCI Form Runtime settings at the database level or at the study level.

At the database level, the DCI Form Runtime settings define the default values when a new study is created. For each setting, you can choose to enforce the default value across all studies in the database or allow modification at the study level. You define the default values in the DCI Form Local Database Settings form.

6.1.1 Defining the DCI Form Runtime Settings at the Database Level

To define the DCI Form Runtime settings at the database level:

1. Open Oracle Clinical.

2. Navigate to Admin and select DCI Form Local Database Settings.

3. Expand the DCI Form Runtime node. See Figure 6-1.

Figure 6-1 DCI Form Runtime Settings for RDC

4. Change the value of the settings you want. The sections that follow provide provide more information about each setting.

5. Select the Enforce Local DB Setting check box to always use this value as the default value.
If not selected, a user who has privileges to the DCI Form Study Database Settings form at the study level can override the default values.

Note that the Enforce Local DB Setting check box is always selected for the Suppress warning for non-migrated CRFs setting because you cannot change its value at the study level.

6. Save your changes.

6.1.2 Defining Report Settings at the Study Level

To define the DCI Form Runtime settings at the study level:

1. Open Oracle Clinical.

2. Navigate to Design and select DCI Form Local Study Settings.

3. Expand the DCI Form Runtime node.

4. Deselect the Inherit From Local DB Setting check box for any value you want to change.

5. Change the value of the settings you want. The sections that follow provide more information about each setting.

6. Save your changes.

6.1.3 Enabling HTML Data Entry for RDC

To allow RDC to collect data by presenting HTML forms to the user, you must configure the correct settings in Oracle Clinical. You enable data entry with DCI Forms at the study level. If you do not enable this setting, RDC does not display the study to the user.

To enable a study to use HTML data entry:

1. Open Oracle Clinical.

2. Navigate to Conduct, Security, and then select Clinical Study States.

3. Query for your study.

4. Select the study from the results of your query.

5. Enable the DCI Forms Entry Enabled? check box.

6. Save your changes.

Note:
The DCI Forms Definition Enabled? setting, which is also in the Clinical Study States form, controls the ability to define DCI Forms for the selected study.

6.1.4 Displaying the Visit-Owning Interval on the Casebooks Page

Use the Display Visit Owning Interval on MPC Page? setting to customize the spreadsheet heading on the RDC Casebooks page.

- If set to Y, the spreadsheet heading on the Casebooks page displays the name of the interval — phase, period, or subperiod — along with the name of the current visit.

- If set to N, the spreadsheet heading on the Casebooks page displays only the name of the current visit. The default value is N.

6.1.5 Allowing Investigator Comments

Use the Enable Entry of Investigator Comments setting to specify whether the RDC application allows users to enter and update investigator comments.

- If set to Y, RDC allows the entry of investigator comments. Users with UPDATE privileges can add investigator comments to a response field and update existing investigator comments. All users can review investigator comments in the Data Entry window and on the Review Investigator Comments page.

- If set to N, RDC does not allow the entry of any investigator comments by any user, regardless of privileges.

6.1.6 Adding a Customized Reference Field to the Search Pane

You can customize the RDC application to include an additional patient-level search field on the Home page and the Casebooks page.

This patient attribute field:

- Lets you search for a particular patient or a set of patients based on the contents of the field

- Can be up to 25 alphabetic, numeric, and special characters

- Supports wildcard searches (%)

To configure the customized field, you need to:

- Specify values for two DCI Form Runtime settings that define a label for the field and enable the customized field

- Write a procedure to populate the Patient Positions table with the user-entered value

6.1.6.1 Searching and Viewing Enhancements for the Customized Field

If you define and enable the custom field, RDC adds the following search and view enhancements to display the patient data associated with your customized field:

- Searching enhancements

- RDC adds your customized field to the Patient Search pane on the Home page and to the Search pane on the Casebooks page.

- When you specify search information in the field, the search runs against the Reported Patient Reference field in the Patient Positions table.

- The customized field supports wildcard searches (%).

- Viewing enhancements

- On the Home page, RDC adds a column to the Patient List and populates the column with the information defined in the Reported Patient Reference field in the Patient Positions table. The column heading uses the same name as the label you defined for your customized field.

- On the Casebooks page, you can position the cursor over the patient icon or the patient number to reveal the data associated with your customized field.

- On the Review CRFs page, Review Discrepancies page, and Review Investigator Comments page, you can position the cursor over the patient number to reveal the data associated with your customized field.

6.1.6.2 Labeling and Enabling Your Customized Search Field

To change the label (or name) of your customized search field, and to enable the field, use the following DCI Form Runtime settings:

- Label for customizable patient identifier — Specifies the text that labels the field. RDC uses this label for the additional search field displayed on the Home page and the Casebooks page, and as the column heading in the Patient List on the Home page. The default value is Reference.

- Use customizable patient identifier? — Defines whether to show or hide your customized search field. If set to Y, RDC enables your customized field, and adds searching and viewing enhancements to the application pages. If set to N, no changes occur in the RDC application. The default value is N.

You can set the default values at the database level, and then change the setting as needed at the study level.

6.1.6.3 Writing the Derivation Procedure to Use Your Customized Field

Your customized patient-level search field on the Home page and the Casebooks page lets RDC users search for a patient based upon the Reported Patient Reference value stored in the Patient Positions table.

To support population of the field, the ocl_utils.update_pat procedure includes an optional parameter (vRepPatRef), which allows the Reported Patient Reference value in the Patient Positions table (rxa_des.patient_position) to be updated.

To populate your customized field:

1. Write a procedure that will be triggered by a DCM of your choosing, such that when the response is entered, the Reported Patient Reference field in the Patient Positions table is populated with a value determined by your procedure.

2. Define your procedure to call the ocl_utils.update_pat procedure to update the Patient Positions table. The ocl_utils.update_pat package includes an optional parameter (vRepPatRef) for the customized Reported Patient Reference field.
If you do not want to change a particular field value for the patient, use rxcpdstd.patients_rec.field-name as a value for that parameter.

Table 6-1 describes the parameters in the ocl_utils.update_pat procedure.

Table 6-1 Parameters in the ocl_utils.update_pat

Parameter

Description

Example Values (assuming alias for DCM Question Group is d)

vMode

- T = Test mode

- P = Production mode

rxcpdstd.v_mode

npatpos

ID for the patient that should be updated

rxcpdstd.patients_rec.patient_position_id

vSex

Value to use to update patient's gender:

- F = female

- M = male

rxcpdstd.patients_rec.reported_sex

or

d.sex

vbirthdate

Value to use to update patient's date of birth

rxcpdstd.patients_rec.reported_birth_date

or

d.birthdate

vinits

Value to use to update patient's initials

rxcpdstd.patients_rec.reported_initials

or

d.inits

vRepPatRef

Value to use to update the patient attribute; the value must be 25 characters or less

rxcpdstd.patients_rec.reported_patient_reference

or

d.reportedPatientRef

Note: This parameter, which is new with this version of the ocl_utils.update_pat procedure, is optional. Therefore, if you have used previous versions, your existing procedures will continue to work.

For example, you can add the following lines to your procedure to update the patient reference using the d.reportedPatientRef question without updating the other values for the patient:

ocl_utils.update_pat (
rxcpdstd.v_mode,
rxcpdstd.patients_rec.patient_position_id,
rxcpdstd.patients_rec.reported_sex,
rxcpdstd.patients_rec.reported_birth_date,
rxcpdstd.patients_rec.reported_initials,
d.reportedPatientRef)

6.1.7 Controlling the Display of Conditional Blocks within a CRF

When defining the questions for a CRF (that is, DCM questions), you can associate one or more conditions with a question. You can define a data response value so that when the user enters that value, other questions and fields become active, and the cursor automatically moves to a specified question within the same CRF. This action is called conditional branching.

With conditional branching, you can define a path through the CRF based on the responses enter. For example, you can use conditional branching to bypass pregnancy-specific questions if the patient is male.

You can the Represent Disabled Blocks As setting to control how RDC displays the conditional blocks within a CRF. You can choose one of the following options:

- Select Greyed if you want RDC to gray out the section in the CRF with the conditional questions. In this case, the user can see the section, but the questions remain disabled until a response value triggers the condition defined for the source question.

- Select Hidden if you want RDC to completely hide the section in the CRF with the conditional questions. The next expected questions, if any, are displayed in the same area, so there is no empty space. The section remains hidden until a response value triggers the condition defined for the source question.
For multi-page CRFs, RDC preserves the locations of page breaks relative to the questions in the form. Therefore, when conditional blocks are hidden, questions from the next CRF page are not moved to fill the resulting additional blank space on the page.

6.1.8 Suppressing Prompts and Warnings

You can use the DCI Form Runtime settings to suppress the:

- Change reason prompt for new responses

- Change reason prompt for new investigator comments

- Warning for non-migrated CRFs

6.1.8.1 Suppressing the Change Reason Prompt for New Responses

By default, RDC requires users to specify a change reason whenever they update any data in a CRF previously saved complete. Updating data includes adding new responses, modifying existing responses, and deleting responses.

If the Suppress Change Reason for New Responses setting is Y, RDC does not prompt users for a change reason when they add a new response (that is, a response entered for the first time) to a CRF previously saved complete. RDC automatically saves the change reason as RESP_ADDED.

Note that RDC considers a response to be new only if:

- The response value is null.

- The response has no audit history.
The existence of an investigator comment or any investigator comment history does not factor into the audit history of a response. If a response is null and has always been null but has an investigator comment, the response is still considered new (that is, being entered for the first time).

You can suppress the change reason prompt when the user updates RDCI comments in accessible documents. For more information, see Section 6.5.2, "Making a Reason for Change Optional for Updates to RDCI Comments in Accessible Documents."

6.1.8.2 Suppressing the Change Reason Prompt for Investigator Comments

If the Suppress Change Reason Prompt for New Investigator Comment setting is Y, RDC does not prompt investigators for a change reason the first time they enter a comment on a particular response.

6.1.8.3 Suppressing the Warning for Non-migrated CRFs

Use the Suppress Warning for Non-migrated CRFs setting to control whether RDC displays a warning message when the user opens a non-migrated CRF.

The Allow HTML Data Entry for Non-migrated CRFs configuration setting controls whether RDC users are able to open and update CRFs that were entered via batch load operation, Oracle Clinical data entry, or RDC Classic data entry, and you choose NOT to migrate those CRFs to DCI Forms.

The Suppress Warning for Non-migrated CRFs setting has meaning only if you allow data entry for non-migrated CRFs:

- If the Allow HTML Data Entry for Non-migrated CRFs configuration setting is set to Y and the Suppress Warning for Non-migrated CRFs setting is set Y, RDC does not display a warning message when the user opens a non-migrated CRF.

- If the Allow HTML Data Entry for Non-migrated CRFs configuration setting is set to Y and the Suppress Warning for Non-migrated CRFs setting is set N, RDC displays a message that the data in the CRF was originally entered using another interface.

See Section 3.3.8, "Allowing Access to CRFs Entered via Oracle Clinical" for more information on allowing data entry for non-migrated CRFs.

6.2 Using DCI Book Assignment

Use DCI Book assignment in any study that uses multiple DCI Books, either sequentially for protocol amendments or in parallel for multi-arm studies. Assigning patients to DCI Books ensures that the correct forms are used for each patient.

Your options for assigning patients to DCI Books are:

- Manually Assigning Patients to DCI Books Using Oracle Clinical

- Automatically Assigning the DCI Book upon Initial Data Entry

- Allowing Patient Book Assignments to Change

Changing the book assignment, either manually or in a validation or derivation procedure, is one way to move a patient from a screening book to a treatment protocol, or from one treatment protocol to another. Likewise, protocol amendments can be introduced in a new DCI Book definition, and patients can be re-assigned to the new book as the protocol amendment is rolled out.

The OCL_STATE local codelist has two values, BOOK_CHANGE and BOOK_ASSIGN, that you can use for DCI Book assignment and re-assignment. Table 6-2 describes the codelist values for assigning DCI books.

Table 6-2 Using DCI Book Assignment

Short Value

Valid Long Values

Description

BOOK_ASSIGN

- Y (default)

- N

Specifies whether RDC automatically assigns a DCI book to the patient upon initial data entry.

BOOK_CHANGE

- ALLOW (default)

- DISALLOW

- DISALLOW IF DATA

Determines whether the DCI book assignment for a patient can change.

6.2.1 Manually Assigning Patients to DCI Books Using Oracle Clinical

To use Oracle Clinical to manually assign patients to DCI Books:

1. Open Oracle Clinical.

2. Navigate to Design, Patient Positions, and then select Patients.

3. Select your study from the list of clinical studies.

4. Click Patient Positions to open the Patient Positions form.

5. Scroll to the right of the form.

6. Enter the DCI Booknames for one or more patients.

6.2.2 Automatically Assigning the DCI Book upon Initial Data Entry

As an alternative to pre-assigning DCI Books by manually updating the Patient Positions table, you can specify that RDC automatically assign each patient to a book upon initial data entry.

Automatic book assignment works as follows:

- You provide instructions, if necessary, to your RDC users as to what book to use for initial data entry.

- If only one book is active in a study at a time, no instructions are necessary.

- If you have multiple active books defined, instructions are needed. When first invoked, the RDC Casebooks page always displays the default casebook you specified at study definition time. RDC uses this casebook for entering data for unassigned patients. However, the user can select another casebook on the Casebooks page.

- When an RDC user enters and saves the first CRF for a patient, RDC automatically assigns the patient to the book in context; that is, RDC updates the Patient Positions table for that patient. Note that the assignment is ONLY made if the patient is currently unassigned.

- Once a patient is assigned to a casebook, RDC enforces use of the casebook for future data entry. The user can no longer change the casebook used simply by changing the casebook in context on the RDC Casebooks page.

To set up automatic book assignment at study definition time:

1. Open Oracle Clinical.

2. Define the DCI Book that RDC uses by default for entering data for patients.

1. Navigate to Definition, DCIs, and then select DCI Books.

2. Select the Default check box for the DCI Book to use as the default.

3. Save your changes.

3. Turn on automatic book assignment.

1. Navigate to Admin, Reference Codelists, and then select Local Codelists.

2. Query for the OCL_STATE local reference codelist. (Enter OCL_STATE in the Name field, and then press F8 to execute the query.)

3. Scroll to the BOOK_ASSIGN short value.

4. Set the long value to Y.
When set to Y, RDC automatically assigns the DCI Book you defined as the default for the study to each patient when data is first entered for the patient.

5. Save your changes.

6.2.3 Allowing Patient Book Assignments to Change

If you make use of a patient book assignment, you may expect the book assignment to change during the course of the study. The following are two examples where this may be the case:

- You define a new DCI Book to account for a protocol amendment. On a site-by-site basis, you update the Patient Positions table to assign patients to the new book.

- You use a Screening book for initial data entry, and based on responses in the Screening CRFs, you assign the patient to one of the arms (casebooks) of a multi-arm study.

To allow a change in the patient or book assignment:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Local Codelists.

3. Query for the OCL_STATE local reference codelist.

1. Enter OCL_STATE in the Name field.

2. Press F8 to execute the query.

4. Scroll to the BOOK_CHANGE short value.

5. Set the long value to ALLOW.

6. Save your changes.

6.3 Specifying CRFs for Single Use

Using options on the Casebooks page, RDC users can add unplanned CRFs and visits for a patient. You can use the SINGLE DCI TYPES installation reference codelist to specify the CRFs that the user cannot add.

The SINGLE DCI TYPES codelist contains the DCI types that do not allow duplicates. The user cannot add any DCI specified in this codelist as unplanned pages to a visit. In addition, if the user adds an unplanned visit to the study, the new visit includes only those DCIs that are not listed in the SINGLE DCI TYPES codelist.

By default, the SINGLE DCI TYPES codelist has the following values:

- DEMOGRAPHY

- COMPLETION

6.4 Customizing the Display of a List of Values

A discrete value group (DVG) is a set of responses (answers) that are acceptable for a given question. In other words, a DVG constrains the response to a distinct list of values (LOV) that are valid for the question. Some examples of questions with a limited list of values are:

- Gender: male, female

- Heart exam: normal, abnormal, not done

- Pain level: 1 (none), 2 (minor), 3 (moderate), 4 (severe), 5 (unbearable)

Using the DVG LOV STYLE setting in the local reference codelist, you can customize the way that Oracle Clinical and RDC display the list of values during data entry for questions associated with a DVG.

This section only describes the effects of the DVG LOV STYLE setting for RDC. For its effect on how Oracle Clinical displays a list of values during data entry, see the Oracle Clinical Administrator's Guide.

To customize how RDC displays a list of valid values for a question:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and Local Codelists.

3. Query for the OCL_DE_CONFIG reference codelist.

1. Enter OCL_DE_CONFIG in the Name field.

2. Press F8 to execute the query.

4. Scroll to the DVG LOV STYLE short value.

5. Specify the long value for DVG LOV STYLE. You can select either SEQ or SHORT.
The long value determines the column order that RDC uses to display the columns of information in the Acceptable List of Values dialog box.

The long value does not determine how RDC sorts the list of values. RDC always sorts the list of values by sequence number.

If you specify SEQ, RDC places the columns in the following order:

- Sequence number, which is titled Display Seq in the LOV. In addition, the sequence number is prefixed with A if it is an alpha DVG value.

- DVG Short Value, which is titled Value in the LOV.

- DVG Long Value, which is titled Description in the LOV.

If you specify SHORT, RDC places the columns in the following order:

- DVG Short Value, which is titled Value in the LOV.

- Sequence number, which is titled Display Seq in the LOV. In addition, the sequence number is prefixed with A if it is an alpha DVG value.

- DVG Long Value, which is titled Description in the LOV.

Note:
If you specify SHORT and no alpha DVG is associated with the DCM question, RDC displays only two columns in the LOV: DVG Short Value and DVG Long Value. It does not display the sequence number column.

6.5 Defining the List of Allowable Change Reasons

By default, RDC requires users to specify a change reason whenever they update data in a CRF previously saved as complete.

As soon as the user updates a field and navigates away from it (by tab or mouse click), RDC displays the Reason for Change dialog box. The user must select one of the allowable reasons from the list.

This section describes how to:

- Customize the list of change reasons that RDC presents to the user, including how to access the codelists and how to define the default reason

- Suppress the Reason for Change dialog box

6.5.1 Accessing the Codelists to Customize the Change Reason Values

You customize the list of change reasons presented in RDC by using the following installation reference codelists:

- DATA CHANGE REASON TYPE CODE — Use this codelist to customize the list of acceptable change reasons for updates made to response or data fields, that is any field except a header field.

- RDCI CHANGE REASON TYPE — Use this codelist to customize the list of acceptable change reasons for updates made to header fields such as Visit date, Visit time, CRF comment, blank flag, lab, or qualifying value.

To access the codelists for customizing the change reasons:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Installation Codelists.

3. Query for the codelist you want to modify.

Table 6-3 lists the initial values in the Data Change Reason Type Code codelist.

Table 6-3 Initial Values for the DATA CHANGE REASON TYPE CODE Codelist

Short Value

Description

DATA ENTRY ERR

Data Entry Error

BATCH

Batch

CRA CORR

CRA Correction

CRA CORR-INV

CRA Correction, Inv consulted

CRA CORR-SRC

CRA Correction, Src Data consulted

INV CORR

Investigator Correction

STUDY ASSUMP

Study Assumption

THES CLARIF

Thesaurus Clarification

ANALYSIS CORR

Analysis Correction

REMOVED

Received DCI Removed

COND VIOLATION

Target responses deleted due to mismatch with conditional response

VAL STATUS CHG

Validation Status changed

COND RESP UPDT

Target responses deleted due to update to conditional response

DATA ENTRY MODE

Data entry mode

6.5.1.1 Reserved Change Reason Values

Oracle Clinical and RDC reserve the following change reasons for system use:

- BATCH

- BROWSE

- KEY CHANGE

- PASS1

- PASS2

- RECONCILIATION

- REMOVED

- TRANSLATION

- UPDATE

You cannot specify these reserved change reasons in either the DATA CHANGE REASON TYPE CODE codelist or the RDCI CHANGE REASON TYPE codelist.

6.5.1.2 Identifying the Default Change Reason

In both the DATA CHANGE REASON TYPE CODE codelist and the RDCI CHANGE REASON TYPE codelist, select a Default check box to mark one of the change reasons as the default. See Figure 6-2.

In a given RDC user session, the first Reason for Change dialog box pre-selects the default change reason, allowing the user to select any other change reason from the list. If the user selects another change reason, subsequent displays of the Reason for Change dialog box pre-select that change reason.

6.5.1.3 Identifying Change Reasons NOT for Use in RDC

RDC data entry uses the same change reason reference codelists that are referenced by Oracle Clinical data entry. To mark any change reason that should not be used in RDC, specify NOTRDC in the Long Value field for the appropriate change reason entry. Figure 6-2.

Note that the NOTRDC setting applies only to RDC. Specifying NOTRDC for a change reason does not affect the use of the change reason in Oracle Clinical data entry or in pre-4.5.3 versions of RDC data entry.

Figure 6-2 DATA CHANGE REASON TYPE CODE Codelist

6.5.2 Making a Reason for Change Optional for Updates to RDCI Comments in Accessible Documents

As described earlier in Section 6.5, "Defining the List of Allowable Change Reasons," RDC requires users to specify a change reason whenever they update data in a CRF previously saved as complete. As soon as the user updates a field and navigates away from it (by tab or mouse click), RDC displays the Reason for Change dialog box. The user must select one of your pre-defined reasons from the list.

You can suppress the change reason prompt when the user updates RDCI comments in accessible documents.

You can, however, choose to make a change reason optional for updates to RDCI comments in accessible documents.

To suppress the Reason for Change dialog box:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Local Codelists.

3. Query for the OCL_DE_CONFIG reference local codelist.

1. Enter OCL_DE_CONFIG in the Name field.

2. Press F8 to execute the query.

4. Scroll to the COMMCHGREAS_REQ short value.

5. Set the long value to N to make a change reason optional for updates to RDCI comments in accessible documents.

6. Save your changes.

6.6 Setting the Format of Dates

You use the Data Entry Preferences form in Oracle Clinical to specify the display and input formats for date fields in RDC. Table 6-4 describes the date preferences that you can set.

The Data Entry Preferences form is available at the database level and at the user level. The database-level preferences for date formats are in effect unless you override that specification at the user level. In addition, if the Preferences link is enabled in RDC, the user can override the values for these options.

Note:
Although user-level settings generally override database-level settings, when a data type discrepancy is raised for a date field, the resulting warning message displays the discrepant date in the format specified at the database level. Therefore, Oracle recommends that you always specify STANDARD (DD-MON-YYYY) as the Data Entry Display Format at the database level.
The other possible values can be misconstrued: US (MM-DD-YYYY), European (DD-MM-YYYY), and Swedish (YYYY-MM-DD).

Note:
Oracle Clinical uses all the preference settings in the Data Entry Preferences form. However, RDC uses only the Data Entry Display Format and the Data Entry Input Format preference settings.

Table 6-4 Data Entry Preferences

Preference

Description

Format

Data Entry Display Format

For DCI and DCM dates and data entry format, the Data Entry Display Format setting determines the format to use for displaying dates. The data entry display format must either be Standard or must match the input format.

You can suppress the day and/or month portion of the data depending on how the question is defined. The display is controlled by the Date Time Format of the DCM question on which it is based. The valid Date Time Formats for a date field are as follows:

- DMY (day, month, and year are displayed)

- MY (only month and year are displayed)

- Y (only year is displayed)

US (mm-dd-yyyy); default

EUROPEAN (dd-mm-yyyy)

SWEDISH (yyyy-mm-dd)

STANDARD (dd-mon-yyyy)

Data Entry Input Format

For DCI and DCM dates and data entry fields of type date, the Data Entry Input Format setting determines how date formats are applied to interpreting data that is input to the field. Must be the same as the Data Entry Display Format setting, unless the display format is set to STANDARD. The standard format is always accepted.

US (mm-dd-yyyy); default

EUROPEAN (dd-mm-yyyy)

SWEDISH (yyyy-mm-dd)

6.6.1 Setting Date Formats at the Database Level

To modify date preferences at the local database level:

1. Open Oracle Clinical.

2. Navigate to Admin, DE Admin, and then select DE User Prefs.

3. Set your preferences for the Data Entry Display Format and the Data Entry Input Format.

4. Click Save as Default to save your changes.

5. Redeploy RDC for the changes to take effect. See "Redeploying RDC with Customizations" for instructions.

6.6.2 Setting Date Formats for Individual Users

To modify the date preferences for an individual user:

1. Open Oracle Clinical.

2. Navigate to Admin, Users and Roles, and then select Oracle Accounts.

3. Press F7 to open the query screen.

4. Enter name of user or enter an account name.

5. Press F8 to display all users that match your specified search criteria. Navigate to the applicable user.

6. Open the Special menu, and then select DE Prefs.

Users can also override the display and entry format by clicking the Preferences link in RDC. This method permanently changes the preference for the user and has the same effect as setting it through Oracle Accounts.

You can customize the RDC application to not display the Preferences link. See Section 3.3.2, "Hiding the Preferences Links" for more information.

7 Customizing RDC on the Application Server

This chapter describes ways to customize RDC by editing files available on the RDC application server.

This chapter includes the following topics:

- Section 7.1, "Modifying Files on the Application Server"

- Section 7.2, "Creating a Launch Page, Button, or Link for RDC"

- Section 7.3, "Customizing the Reset Password Link"

- Section 7.4, "Customizing Branding Images in RDC"

- Section 7.5, "Customizing the Contact Us Link"

- Section 7.6, "Customizing the Change Password Link"

- Section 7.7, "Customizing the Electronic Signature (Approval) Warning Message"

- Section 7.8, "Customizing the Logout Message"

- Section 7.9, "Setting the User Session Timeout Value"

- Section 7.10, "Setting the Maximum Number of Rows Fetched"

- Section 7.11, "Storing Custom Web Pages"

- Section 7.12, "Storing the DCIF Images"

- Section 7.13, "Customizing the Single View of the Patient Casebooks Page"

- Section 7.14, "Hiding Unplanned Visit Buttons in RDC Onsite"

7.1 Modifying Files on the Application Server

You can use several system files on the application server to customize settings for RDC. Some of the system files that you can modify include:

- In the RdcLogos.properties file, you can define a custom URL for the Reset Password link and the Contact Us link in the RDC application. You can also specify a co-branding logo.
The RdcLogos.properties file is located in OPA_CONFIG_FOLDER path. This path comes from registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

- In the RdcTexts.properties file, you can customize the Change Password link, customize the logout message, and modify the text of approval warning messages.
The RdcTexts.properties file is located in OPA_CONFIG_FOLDER path. This path comes from registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

- In the rdcConfig.properties file, you can set the session timeout value, specify the maximum number of rows (data records) to retrieve, and enable server profiling.
The rdcConfig.properties file is located in the OPA_CONFIG_FOLDER path. This path comes from the registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

For more information on modifying the system files, see Chapter 15, "Collecting Debug Data."

Before modifying a system file, you must stop WebLogic Admin Server. See Section 1.5, "Stop the WebLogic Admin Server" for more information.

7.2 Creating a Launch Page, Button, or Link for RDC

This section provides instructions for customizations such as:

- Section 7.2.1, "Creating or Customizing a Launch Page to Use Provided Scripts"

- Section 7.2.2, "Customizing the Remote Data Capture URL"

- Section 7.2.3, "Adding Custom Text to the RDC Onsite Login Page"

7.2.1 Creating or Customizing a Launch Page to Use Provided Scripts

Oracle recommends using the scripts provided here to control when and how the RDC Login page opens, to prevent users from having problems in the RDC application resulting from:

- Using the browser's Back button—Sample Java Script for Launching in a New Window without Tool or Menu Bar suppresses the browser toolbar, making the Back button unavailable.

- Turning on Internet Explorer's Compatibility View—Sample JavaScript for Checking if Compatibility View Is On detects if Compatibility View is turned on and if it is, does not open the application and displays a message telling the user to turn it off.

- Opening more than one RDC session to the same application server or from the same parent window—the scripts prevent this.

To use these scripts in your launch page:

1. Place the script from Section 7.2.1.1, "Sample Java Script for Launching in a New Window without Tool or Menu Bar" in a file called Launch.js.

2. Place the script from Section 7.2.1.2, "Sample JavaScript for Checking if Compatibility View Is On" in a file called IeCompatCheck.js.

3. Place the scripts at the same location as the Launch page or in a folder (called JS in the example code below) in the same location as Launch page. The shipped Oracle Clinical Launch page, launch.htm, is located in opa_home/html.

4. Create an HTML page that contains a button or link to RDC that invokes the functions in the JavaScript files or add code to the shipped Launch page or an existing website to do the same.
Put the code referencing the scripts near the top of the HTML page; for example:

<title> Launch RDC </title>
<script type="text/javascript" src="JS/IeCompatCheck.js"></script>
<script type="text/javascript" src="JS/LaunchJS.js"></script>

</head>
<body>

Add button code or link code as follows, and see Section 7.2.2, "Customizing the Remote Data Capture URL."

<script language="JavaScript">
document.write('<FORM>');
document.write('<input type="button" value="RDC" onclick="return launch(event,\'../rdcadfsrnd/faces/Login\',\'RDC\')" class="loginButton"/>');
document.write("</FORM>");
</script>

<noscript>
<a onclick="return launch(event,'../rdcadfsrnd/faces/Login',\'RDC\')" href="#">Launch RDC</a>
</noscript>

7.2.1.1 Sample Java Script for Launching in a New Window without Tool or Menu Bar

function launch(event,url,windowname){
if(detectIECompatibility(event)){
cancelEvent(event);
return false;
}
if(!!!windowname){
windowname="_blank";
}
}

7.2.1.2 Sample JavaScript for Checking if Compatibility View Is On

The following script checks if compatibility view is on and if so, displays a message asking the user to turn it off.

function IECompatDetect(){
this.isCompatOn = function(){
var ua = navigator.userAgent;
var on = false;
for(var index=0; index< this.ieUAProps.length; index++){
var ieProp = this.ieUAProps[index];
if(ua.search(ieProp.layoutEngine) == -1){
continue;
}
if(ua.search(ieProp.browser) == -1){
on = true;
break;
}
}
return (on);
};
this.ieUAProps= [
{
browser: 'MSIE 10',
layoutEngine: 'Trident/6'
},
{
browser: 'MSIE 9',
layoutEngine: 'Trident/5'
},
{
browser: 'MSIE 8',
layoutEngine: 'Trident/4'
}
]

}
function cancelEvent(e){
var event = e || window.event;
if(event == null){
return;
}
if(event.preventDefault){
event.preventDefault();
}else{
event.returnValue=false;
event.cancelBubble=true;
}
}

function compatCheck(event,isCompatRequiredToBeOn){
var compatOn=(new IECompatDetect()).isCompatOn();
if(compatOn && !isCompatRequiredToBeOn){
cancelEvent(event);
alert("Please turn off IE's Compatibility View. Go to Tools->Compatibility View/Compatibility View Settings to do so.");
}
if(!compatOn && isCompatRequiredToBeOn){
cancelEvent(event);
alert("Please turn on IE's Compatibility View. Go to Tools->Compatibility View/Compatibility View Settings to do so.");
}
return compatOn;
}
function detectIECompatibility(e){
return compatCheck(event,false);
}

//Call on load
(function(){
compatCheck(null,false);
})();

7.2.2 Customizing the Remote Data Capture URL

You can add optional parameters to the RDC URL to change the behavior at run time. The format of the URL is as follows:

https://server.domain/rdcadfsrnd/faces/Login?setUpDone=Y &parameter1=value1&parameter2=value2

Table 7-1 describes the parameters that you can use in the URL.

Table 7-1 RDC URL Parameters

Parameter

Description

Example

setUpDone

To display the Middle Tier server name in the lower left corner of the RDC Surround (all user interface pages except the Data Entry window) and in the RDC Launch page, set this parameter to Y.

If you don't want to show the Middle Tier server name, remove this parameter or set its value to N.

setUpDone=Y

db

Specifies the database to connect to for RDC. If not specified, the application connects to the default database.

Use this parameter to connect to a database that is not set up as the default. See Appendix A, "Setting Up Database Connections" for information about specifying the default database and ensuring that your application server can access any database you specify with this parameter.

db=mydb

debug

Specifies whether to enable debugging and logging.

all — Debugs all modules.

surround — Debugs only the RDC application pages.

de — Debugs only the Data Entry window.

Oracle Support may ask you to use this parameter to diagnose issues. See Chapter 15, "Collecting Debug Data" for more information.

debug=all

deparams

Oracle Support may ask you to use this parameter to diagnose possible performance issues by profiling HTML requests and responses using a value of profile. The value xhrd is reserved for possible tuning purposes.

To be provided by Oracle Support

display_descpId

Specifies whether RDC displays the discrepancy identifier in an additional column on the Review Discrepancies page and in the Discrepancy Details window. See Chapter 15, "Collecting Debug Data" for more information.

display_descpId=Y

display_docnum

Specifies whether RDC displays the document (CRF) number in an additional column:

- On the Review CRFs page

- On the Review Discrepancies page

- In the Discrepancy Details window

- On the Review Investigator comments page

See Chapter 15, "Collecting Debug Data" for more information.

display_docnum=Y

mode

Specifies the mode in which the RDC application runs.

T — Runs in test mode.

P — Runs in production mode. Production mode is the default, if not specified.

mode=T

sqlTrace

Specifies whether to enable SQL tracing.

- 1 — Enables SQL tracing.

- Any other value — Disables SQL tracing.

Oracle Support may ask you to use this parameter to diagnose possible SQL issues. See Chapter 15, "Collecting Debug Data" for more information.

sqlTrace=1

showMachineName

Indicates how to display the Middle Tier server name. You set this parameter along with setUpDone, in the rdcconfig.properties file.

You can specify values as follows:

- Y: Display the complete name of the Middle Tier server.

- n, where n is a number: Display the first n characters of the Middle Tier server name.

- Anything else: Displays the first four characters of the Middle Tier server name if setUpDone=Y.

showMachineName=15

7.2.3 Adding Custom Text to the RDC Onsite Login Page

You can show a disclaimer of informative text on the RDC Onsite login page.

To add custom text to the RDC Onsite login page:

1. Open the file RDCText.properties in a text editor.

2. Look for the prompt.login.disclaimer parameter and add your text as the value for this parameter. You can add up to 300 characters.

3. Save your changes and close the file.

4. Open the file RDCLogos.properties in a text editor.

5. Look for the show.Disclaimer parameter and set its value to true.

6. Save your changes and close the file.

7. For these changes to take effect, restart the application server.

7.3 Customizing the Reset Password Link

By default, the Login page for the RDC application does not include the Reset Password link.

You can:

- Choose to show the Reset Password link on the Login page

- Specify a URL for your own reset password page or use the RDC Onsite Reset Password utility

7.3.1 Requirements for Using the RDC Onsite Reset Password Utility

The RDC Onsite Reset Password utility uses functionality in the Oracle Thesaurus Management System (TMS). Therefore, to make use of the reset password utility:

- TMS must be installed, either on the RDC application server or on another accessible server.

- The TMS user IDs must match the RDC user IDs.

- Email addresses for all RDC users must be specified in TMS using the TMS user interface. If users click the Reset Password link and their user IDs and e-mail addresses are not specified in TMS, the process fails and RDC displays an error message.

For more information on creating user IDs and specifying e-mail addresses in TMS, see the Oracle Thesaurus Management System User's Guide.

7.3.2 Resetting versus Changing Passwords

If a user attempts to log in to RDC with a valid but expired password, RDC redirects the user to the Change Password page. The password can be changed strictly through the user interface, without e-mail or involvement of TMS.

See Section 7.6.1, "Changing the URL and the Name for the Change Password Link" for more information.

7.3.3 Configuring the Reset Password Link

You use the RdcLogos.properties file to change the default settings for the Reset Password link.

To configure the Reset Password link:

1. Navigate to the OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52, found under HKEY_LOCAL_MACHINE > Software > Oracle, for example:
C:\opapps52\config

2. Open the RdcLogos.properties file with a text editor.

3. Find the following line in the file and set the value to true to display the Reset Password link on the Login page:
image.ResetPasswordUrlRendered=true

4. Specify the Reset Password page that displays when the user clicks the Reset Password link. You can specify your custom Reset Password page or you can use the RDC Onsite Reset Password page.

- To specify your custom page, find the following line in the file and set the value to the URL for your Reset Password page:
image.ResetPasswordUrl=Custom_URL

- The RDC Onsite Reset Password page requests the username and then sends a new password by email to their registered email address. By default, the link for this page is not enabled. You can enable the link to this page and configure the email functionality. To use the RDC Onsite Reset Password page:

1. Make sure the following line is not set to a value:
image.ResetPasswordUrl=

2. Verify that the following value is set as indicated below:
image.ResetPasswordUrlRendered=true

3. Adjust for an SSL or non-SSL authentication:
If the email server uses SSL authentication, set values as follows:

resetPassword.email.smtp.auth=true

resetPassword.email.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory

If the email server does not use SSL authentication, set values as below:

resetPassword.email.smtp.auth=false

resetPassword.email.smtp.socketFactory.class=

4. Set the values for the below parameters:
resetPassword.email.smtp.host: Set to the name of the SMTP host that is set up to send emails.

resetPassword.email.from: Set to the sender name to be displayed on sent emails.

resetPassword.email.username: Set to the email account on the SMTP host that is used to send the email.

resetPassword.email.password: Set to the password for the email account that is sending the email messages. Leave this parameter blank if the password is not required by the server.

resetPassword.email.smtp.port: Set to the port used by the SMTP server. Common values are 465 for SSL-enabled servers, or 25 for non-SSL servers.

5. You can customize the messages of the SMTP host for password changes. The message parameter and default values are listed below.
resetPassword.email.message.subject: The default text is Reset Password Request for {0}, where {0} is replaced by the username for which the password is reset.

resetPassword.email.message.body: The default text is This message confirms that your password has been reset. The new password for user {0}, database {1} is: {2}, where {0} is replaced by the username for which the password is reset, {1} is replaced by the name of the database, and {2} is replaced by the new password.

resetPassword.error.failed.text: The default text is Failed to reset password. Please contact your help desk.

resetPassword.error.nousername.text: The default text is Please provide a valid username.

resetPassword.error.failedemail.text: The default text is Your Password has been reset, however the e-mail notification failed to launch. Please contact your system administrator.

resetPassword.confirm.text: The default text is Your Password has been reset. Please check your e-mail for the new password.

5. Save your changes.

6. Restart the OPA server.
For details, see Section D.5, "Restarting the OPA Server".

7.4 Customizing Branding Images in RDC

In RDC, the page header displays the Oracle logo as the product logo in the top-left corner by default and also allows for adding a co-brand logo in the top-right corner. You can customize the application to add your own product image and a co-brand logo.

To customize the product and co-brand images:

1. Create one or both image files in any format (for example JPG, GIF), as follows:

- Product branding image: width of 155 pixels and height of 20 pixels.

- Co-brand logo image: width of 100 pixels and height of 20 pixels.

2. Copy the image files to the OPA_HOME\html\images folder. For example, C:\opapps52\html\images.

3. Navigate to the middleware_home\asinst_1\config\OHS\ohs1\moduleconf folder.

4. Open the file opa52_httpd.conf in a text editor and, if not already set, add an alias for opa52, pointing to the html folder:

alias /opa52/ "C:\opapps52/html/"

5. Save your changes and close the opa52_httpd.conf file.

6. Open the RdcLogos.properties file in a text editor. This file is in the OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52, found under HKEY_LOCAL_MACHINE > Software > Oracle.

7. To replace the product brand image that appears in the top-left corner of the RDC pages:

1. Find the string image.ProductBranding=images/FNDSSCORP.gif, where images is the folder where you placed the image. This folder may have a different name in your environment.

2. Replace the text FNDSSCORP.gif with the name of the product brand image you created for step 1.

8. To place a co-brand in the top-right corner of the RDC pages:

1. Find the string image.CoBranding=images/co_brand.jpg.

2. Replace co_brand.jpg with the name of the file containing the co-brand image you placed in the images folder at step 1.

3. Find the string image.CoBrandingRendered=false and replace the value with true.

9. Save your changes and close the RdcLogos.properties file.

10. Restart the OpaServer1 from the WebLogic Admin Console for the changes to take effect.

7.5 Customizing the Contact Us Link

By default, the RDC application does not include the Contact Us link with the other global links that display in the page header and the page footer.

You can indicate whether you want the Contact Us icon to appear, and if so, its target URL.

To customize the Contact Us link:

1. Stop the WebLogic Admin Server.

2. Log in to the RDC application server.

3. Navigate to the OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52, found under HKEY_LOCAL_MACHINE > Software > Oracle.

4. Open the RdcLogos.properties file with a text editor.

5. Find the following two lines in the file:
image.ContactUsUrl=https://support.oracle.com/
image.ContactUsUrlRendered=false

6. Make the following changes:

1. Replace the support.oracle.com Web address with the URL of the Web page that you want users to access when they click the Contact Us link.

2. Set image.ContactUsUrlRendered=true to display the Contact Us link in the RDC application.

7. Save your changes.

8. Restart the WebLogic Admin Server instance.

7.6 Customizing the Change Password Link

By default, the Change Password link appears in the page header and the page footer of the RDC application pages, along with the other global links. You can customize this link to point to your own change password page by editing the RdcTexts.properties file.

The RdcTexts.properties file is located in OPA_CONFIG_FOLDER. This path comes from the registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

In addition, using SQL commands, you can customize password profiles that affect whether the Change Password page is invoked automatically during the grace period or after the password has already expired.

Your options for customizing the Change Password link include:

- Changing the URL and the Name for the Change Password Link

- Enforcing Profile Limits for the Change Password Page

7.6.1 Changing the URL and the Name for the Change Password Link

By changing the URL, you can customize the page that your users see when they click the Change Password link.

You can also change the name of the Change Password link. You cannot, however, hide the link. The Change Password link always displays in the RDC application.

To customize the URL and name for the Change Password link:

1. Stop the WebLogic Admin Server.

2. Log in to the RDC application server.

3. Navigate to OPA_CONFIG_FOLDER. Its path comes from the registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

4. Open the RdcTexts.properties file with a text editor.

5. Find the following text string and specify your custom URL:
url.ChangePassword=rdcUserPreferences.do?pagetype=

6. Find the following text string and enter the text for the name of the Change Password link:
button.ChangePassword=

7. Save your changes.

8. Restart the WebLogic Admin Server.

7.6.2 Enforcing Profile Limits for the Change Password Page

Passwords have a lifetime and a grace period defined by database profiles. You can set an expiration date for passwords. Accordingly, RDC prompts users to change their password as the expiration date approaches.

Users have a grace period in which to change their password. If they log in during the grace period, RDC displays a warning message that their password will expire soon and automatically redirects them to the Change Password page. Users can choose to change their password now or wait until later. RDC lets users log in.

If users do not change their password during the grace period, the password will expire. However, the opportunity to change the password still exists. If users attempt to log in with an expired password, RDC automatically redirects them to the Reset Expired Password page. In this case, users cannot continue until they successfully change their password. Users must then log in with their new password.

To ensure that the profile limits are enforced, use the following SQL command to assign a profile to a user:

ALTER USER user-name PROFILE profile-name

7.7 Customizing the Electronic Signature (Approval) Warning Message

Whenever a user approves a CRF or a group of CRFs in RDC, the approval represents an electronic signature provided in accordance with FDA 21 CFR Part 11.

Every time the user approves a CRF or undoes the approval for a CRF, RDC issues a standard warning message that appears in the same window as the approval. You can customize this message.

Users can select options in the Data Entry window or options on the application pages to approval CRFs. Therefore, if you decide to customize the approval warning message, make sure you change the message for both locations in the user interface.

7.7.1 Customizing the Approval Warning Messages for the Data Entry Window

To customize the approval warning messages for the Data Entry window:

1. Make a copy of olsardc.ear from the upload folder or equivalent pat: middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear

2. Open olsardc.ear using any utility to unzip.

3. From there traverse to the location of de_external.properties in the following path:
middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\lib\rdcdataentry.jar\oracle\pharma\rdc\de\resource\properties\de_external.properties

4. Open the de_external.properties file with a text editor.

5. Modify the Approval warning message:

1. Find the following text string:
de.dcs.approve.signoff=

2. Change the text following the equal symbol (=) to the message that displays when the user approves a CRF from the Data Entry window. The default text is:
de.dcs.approve.signoff=IMPORTANT By approving this CRF page, you confirm that all data on the page is complete and correct. This approval is equivalent to an electronic signature.

6. Modify the Undo Approval warning message:

1. Find the following text string:
de.dcs.unapprove.signoff=

2. Change the text following the equal symbol (=) to the message that displays when the user undoes the approval from the Data Entry window. The default text is:
de.dcs.unapprove.signoff=IMPORTANT By undoing approval, you are rescinding the electronic signature on this page.

7. Save your changes.

8. Click Ok when prompted to replace the modified files in the war and ear.

9. Close the unzip utility.

You now need to deploy the customization. See Appendix D for instructions.

7.7.2 Customizing the Approval Warning Messages for the Application Pages

To customize the approval warning messages for the application pages:

1. Stop the WebLogic Admin Server.

2. Log in to the RDC application server.

3. Navigate to OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

4. Modify the Approval warning message:

1. Find the following text string:
prompt.ApproveCrfWarning2=

2. Change the text following the equal sign (=) to the message that displays when the user approves a CRF from an application page. The default text is:
prompt.ApproveCrfWarning2=By approving this group of CRFs, you confirm that all data are complete and correct. Each approval is equivalent to an electronic signature.

5. Modify the Undo Approval warning message:

1. Find the following text string:
prompt.UnApproveCrfWarning2=

2. Change the text following the equal sign (=) to the message that displays when the user undoes the approval from an application page. The default text is:
prompt.UnApproveCrfWarning2=By undoing the approval of this group of CRFs, you revoke prior certification that the data was complete and correct. Each un-approval is equivalent to removal of an electronic signature.

6. Save your changes.

7. Restart the WebLogic Admin Server instance.

7.7.3 Other Options for Customizing Approvals

In addition to customizing the approval warning messages, you can:

- Disable approval from RDC. See Section 3.3.4, "Allowing CRF Group Actions" for more information.

- Set a timeout value for pre-population of user name for approvals. See Section 8.2, "Configuring a Timer Period for Subsequent Electronic Signatures" for more information.

7.8 Customizing the Logout Message

By default, RDC displays the following message when you log out of the application:

You can customize this message by editing the RdcTexts.properties file. You may want to provide additional information or hints — such as exit from Internet Explorer or delete the browsing history — that users should do after logging out.

To customize the logout message for the RDC application:

1. Stop the WebLogic Admin Server.

2. Log in to the RDC application server.

3. Navigate to the OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52, found under HKEY_LOCAL_MACHINE > Software > Oracle.

4. Open the RdcTexts.properties file in a text editor.

5. Find the following parameters and update their values to customize the logout message:

logout.msg.normal.1=You are successfully logged out. Click
logout.msg.normal.2= to log in again.
logout.msg.timedout.1=Your session timed out. Click
logout.msg.timedout.2= to log in again.
logout.msg.changepassword.1=Your Password has been changed successfully. Click
logout.msg.changepassword.2= to log in with new credentials.

6. Save your changes and close the file.

7. Restart the WebLogic Admin Server instance.

7.9 Setting the User Session Timeout Value

A session begins when a user successfully logs in to RDC. The session ends either when the user logs out or when RDC times out due to inactivity.

By default, RDC times out after 30 minutes of inactivity. However, you can change the timeout interval to another value. If a user remains inactive in a session for the specified period of time, RDC automatically times out and logs the user out of the application.

The automatic timeout provides added security to unauthorized use of the application. If a timeout occurs, RDC prompts the user to log in again.

7.9.1 Recommendations for Setting the Session Timeout Value

When determining whether to increase the session timeout to more than 40 minutes, you must consider the following issues:

- High timeout values may negatively affect performance and scalability because memory usage increases as the timeout value increases. Specifically, when a session times out, the system cleans out all resources assigned to the user. Increasing the timeout value means the system continues to use resources for a longer time. However, if the number of concurrent users accessing the system is low (that is, 25–50), you may not notice that resources are used for a longer time, and therefore, you may not experience any resource problems. Furthermore, if you have correctly configured your server for the number of users accessing the system, you should not experience any problems with memory or CPU resources.

- The value for the jbo.ampool.maxinactiveage setting in the bc4j.xcfg file must be set higher than the session timeout. The default value for this setting is 60 minutes. Therefore, you must also edit the jbo.ampool.maxinactiveage setting if you set the session timeout to 120 minutes (1200000).

For additional information about the various configuration settings you can use to improve the performance of RDC, consult the following white paper on My Oracle Support:

Document Name: Oracle Clinical Remote Data Capture Onsite and Thesaurus Management System Browser Infrastructure Tuning Tips for Releases 5.0.1 and 5.1

Document ID: 1965232.1

Also see the page Oracle Clinical and Oracle Clinical Remote Data Capture 5.2 Documentation on the Oracle Help Center (http://docs.oracle.com) for the most recent product documentation.

7.9.2 Changing the Session Timeout Value

To change the timeout interval for an RDC session:

1. Stop the WebLogic Admin Server instance.

2. Log in to the RDC application server.

3. Navigate to the OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52, found under HKEY_LOCAL_MACHINE > Software > Oracle.

4. Open the RdcConfig.properties file with a text editor.

5. Find the following line and edit the value (number of minutes) to change the session timeout limit:
rdc_session_timeout=30

Note:
If you set the session timeout to more than 59 minutes, you must also change the value for the jbo.ampool.maxinactiveage setting in the bc4j.xcfg file to be greater than the value of the session timeout.

6. Save your changes.

7. Restart the WebLogic Admin Server instance.

7.10 Setting the Maximum Number of Rows Fetched

By default, RDC retrieves a maximum of 1000 rows of data (records) whenever you open the Home page or execute a search.

You can change the default value by adding the max_row_fetched parameter to the RdcConfig.properties file. You specify the maximum number of rows that RDC can retrieve from the database at a time. When you execute a search, RDC issues a warning message to adjust the search criteria if your query would retrieve more rows than the maximum number allowed.

Note:
Increasing the value is likely to degrade performance. Reducing the value may improve performance for any given search, but may require more searches to be executed by the user.

To change the maximum number of rows fetched:

1. Log in to the RDC application server.

2. Navigate to the OPA_CONFIG_FOLDER. The path is determined by the registry entry opa52 under HKEY_LOCAL_MACHINE > Software > Oracle.

3. Open the rdcConfig.properties file with a text editor.

4. Update the value for max_row_fetched in the file. The default value is 1000.

5. Save your changes.

7.11 Storing Custom Web Pages

Custom pages can be kept in the following folder:

middleware_home\user_projects\domains\OPADomain\servers\HOST_NAME_OPA_INSTANCE_NO\tmp\_WL_user\olsardc_release-build\deployment-specific_folder\war\

For example, the location for a test.pdf file would be:

middleware_home\user_projects\domains\OPADomain\servers\blr2211071_OPA_1\tmp\_WL_user\olsardc_5.2.0.0.20-b00\pqp2wi\war\test.pdf

The URL corresponding to the same test.pdf file used as example is:

<a target="_blank" href="https://XXXXX/rdcadfsrnd/test.pdf">https://XXXXX/rdcadfsrnd/test.pdf</a>

Use this directory to save the custom Web pages that you create for CRF online help and for the Links section on the Home page.

For information on creating and maintaining links, see Chapter 11, "Configuring Links."

7.12 Storing the DCIF Images

Form designers can embed logos or other images in their forms.

To enable image viewing on CRFs during data entry in RDC, you can choose either to set up a central repository or to copy images to all RDC installations. For information on enabling image viewing, see the Oracle Clinical Administrator's Guide.

7.13 Customizing the Single View of the Patient Casebooks Page

You can choose to activate or deactivate single view for the Patient Casebooks page (Single Patient Casebooks). If it is active, you can configure RDC so that patient numbers on the Home page are links that navigate to the single view Patient Casebooks page.

7.13.1 Activating One-Click Navigation to the Single View of Patient Casebooks Page

With this feature activated, patient numbers on the RDC Home page are links that navigate to the single view of the Patient Casebooks page for that patient.

To activate this feature:

1. Open the RdcLogos.properties file in a text editor.

2. Find the feature.Enable_PtID_SPC_Links parameter and change its value from 0 to 1.

3. Save your changes and close the file.

4. For the change to take effect, restart the application server.

7.13.2 Deactivating the Single View for the Patient Casebooks Page

To deactivate single view for the Patient Casebooks page:

1. Open the RdcLogos.properties file in a text editor.

2. Find the feature.EnableSPCB parameter and change its value from 1 to 0.

3. Save your changes and close the file.

4. For the change to take effect, restart the application server.

7.14 Hiding Unplanned Visit Buttons in RDC Onsite

If you don't want to allow RDC Onsite users to add unplanned visit pages using the Add Visit Page button or to add additional pages to visits using the Add Other Page button, you can hide one or both of these buttons from the Patient Casebooks page. For details about these buttons, see the section "Adding Pages" in the Oracle Clinical Remote Data Capture User's Guide.

To hide the buttons:

1. Open the RdcLogos.properties file in a text editor. or . Change the default value for the parameter from 1 to 0. Restart the OpaServer1 for the changes to take effect.

2. Find the parameter corresponding to the buttons you want to hide: feature.EnableAddVisitPage and feature.EnableAddOtherPage.

3. Change the value for a parameter from 1 to 0 to hide the corresponding button.

4. Save your changes and close the file.

5. For the changes to take effect, restart application server.

8 Working with the RDC Client Package

The RDC Client package contains PL*SQL procedures that you can modify to customize various aspects of how the RDC application behaves. For example, you can customize document numbers, set how often RDC requests user names and password for approvals, and customize bookmark labels for a Patient Data Report.

To make these custom changes, you only need to modify the procedures in the RDC package body for the client:

rdcpb_client.sql

Note:
Do not modify the RDC package specification for the client (rdcps_client.sql).

This chapter includes the following topics:

- Deriving Company-Specific Document Numbers

- Configuring a Timer Period for Subsequent Electronic Signatures

- Configuring the DCI Bookmark Label for the Patient Data Report

- Configuring the DCM Bookmark Label for the Patient Data Report

- Configuring the Visit Bookmark Label for the Patient Data Report

8.1 Deriving Company-Specific Document Numbers

Function Name:

DeriveDocumentNumber

Purpose:

Derives an identification number from the key fields of the document. Modify the code according to your business rules. For example, you may want to make the site number part of the document number.
The DeriveDocumentNumber function serves the same purpose as the DeriveDocumentNumber function in the Oracle Clinical package. If you customized code for the Oracle Clinical package, you can copy and paste that code into the RDC Client package.

Parameters:

study (in varchar2) — Denotes the name of the study.
clinical_study_id (in number) — Denotes the ID number of the study.

patient (in varchar2) — Denotes the code name (external identifier) of the patient.

patient_position_id (in number) — Denotes the position number of the patient.

investigator (in varchar2) — Denotes the code name of the investigator.

investigator_id (in number) — Denotes the ID number of the investigator.

site (in varchar2) — Denotes the code name of the site.

site_id (in number) — Denotes the ID number of the site.

DCI (in varchar2) — Denotes the name of the data collection instrument (DCI).

dci_id (in number) — Denotes the ID number of the DCI.

event (in varchar2) — Denotes the name of the clinical planned event.

clin_plan_eve_id (in number) — Denotes the ID number of the clinical planned event.

subevent (in number) — Denotes the ID number of a subtype of the planned event.

rxc_env_type (in varchar2) — Denotes the environment type, where T indicates Test mode and P indicates Production mode.

Return Value:

Returns the ID number as a varchar2. The default is a system-generated sequence number.

Default Logic:

Returns "R" concatenated to the next value from sequence Received_dci_seq2.

8.2 Configuring a Timer Period for Subsequent Electronic Signatures

Function Name:

htmlde_timeout_mins

Purpose:

Sets the time period in minutes for when users performing approvals in RDC will need to re-enter their user name.
The first time a user attempts to approve a CRF in a session, RDC prompts for both a user name and a password. After the first approval, the defined time period starts. During the time period, the user can approve many CRFs. For these subsequent approvals, RDC prompts only for a password.

When the time period expires, RDC again prompts for both a user name and a password before approving the CRF. The time period then restarts. The user only needs to enter a password on subsequent approvals until the time period expires.

Parameters:

None.

Return Value:

Returns an integer that specifies the number of minutes for the time period.

Default Logic:

10 (that is, 10 minutes).

8.3 Configuring the DCI Bookmark Label for the Patient Data Report

Function Name:

get_dci_label

Purpose:

Lets you customize the label used for a DCI in the bookmark of the Patient Data Report.
By default, this function returns the name of the DCI. You may want to customize this function to return the short name or to use the unique dci_id to retrieve a label from another table or system.

Parameters:

pDciId — Denotes the ID of the DCI.

Return Value:

Returns the text that is displayed for a DCI in the bookmark of the Patient Data Report.

Default Logic:

Returns the name of a DCI.

Related Functions:

get_dcm_label
get_visit_label

8.4 Configuring the DCM Bookmark Label for the Patient Data Report

Function Name:

get_dcm_label

Purpose:

Lets you customize the label used for a DCM in the bookmark of the Patient Data Report. RDC calls this function only if the local database setting for the data domain is set to DCM.
By default, this function returns the name of the DCM. You may want to customize this function to return the description or to use the unique combination of dcm_id, dcm_subset_sn, dcm_layout_sn, and qualifying_value to retrieve a label from another table or system.

Parameters:

pDcmId — Denotes the ID of the DCM.
pDcmSubset — Denotes the subset number of the DCM.

pDcmLayout — Denotes the layout number of the DCM.

pDcmQualVal — Denotes the qualifying value of the DCM.

Return Value:

Returns the text that is displayed for a DCM in the bookmark of the Patient Data Report.

Default Logic:

Returns the name of a DCM.

Related Functions:

get_dci_label
get_visit_label

8.5 Configuring the Visit Bookmark Label for the Patient Data Report

Function Name:

get_visit_label

Purpose:

Lets you customize the label used for a visit in the bookmark of the Patient Data Report.
By default, this function returns the name of the visit (that is, the clinical planned event). You may want to customize this function to return the description, to return the phase, or to use the unique clin_planned_event_id to retrieve a label from another table or system.

Parameters:

pClinPlanEveId — Denotes the ID of the clinical planned event.
pSubEventNo — Denotes the subevent number.

Return Value:

Returns the text that is displayed for a visit in the bookmark of the Patient Data Report.

Default Logic:

Returns the name of a visit.

Related Functions:

get_dci_label
get_dcm_label

9 Configuring News

News items are messages that the study sponsor wants to communicate to all, some, or one of its RDC users. For example, the news might be about study protocol, upcoming deadlines, daily reminders, or weekly status.

To define the news items, you use the News Definition for Remote Data Capture form in the RDC Administration application. You can customize the news information according to the current study, site, user, role, or date.

Any user with RDC administrator privileges can customize news content. In addition, you can grant a user the privilege to define news content, but not perform other administrator tasks. Granting others this privilege makes it easy to update daily and site-specific news.

This chapter includes the following topics:

- About the News Section in RDC

- Creating User Roles that Can Define News Items Only

- Creating and Modifying News Items

- Querying News Definitions

9.1 About the News Section in RDC

RDC displays news items as links in the News section on the Home page. Your users see the news headlines as soon as they log in to the RDC application.

RDC supports an unlimited number of news items. Figure 9-1 illustrates two links in the News section along with the details that display when the user clicks the link. Note that each news item can include a URL that links to additional information.

You define the headline text, the detailed message, and the optional URL. When defining the news details, you can use substitution parameters to create messages with personalized greetings and changing dates.

Figure 9-1 Reading the Daily News in RDC

9.2 Creating User Roles that Can Define News Items Only

By default, any user with one of the following roles can perform all RDC administrative tasks, including the task of defining news items:

- RXC_ADMIN

- RXC_SUPER

- RXC_SUPER_NOGL

- RXC_DES

- RXC_DMGR

You can also create a different set of roles with limited administrator privileges. For example, you can grant a user the privilege to define news content only. Granting others this one privilege makes it easy to update daily and site-specific news.

Note that the process you use to create the user roles that have privileges to define news content is different from the process for creating the user roles for other administrative privileges. Therefore, you can identify user roles for defining news content that are different from the roles for performing other administrative tasks.

To create or modify the set of user roles that can define news items only:

1. Log in to the Oracle Clinical database server.

2. Navigate to the Oracle Clinical INSTALL directory.

3. Open the opapb_level_privs_m1.sql file with a text editor.

4. Find the admin_user function.

- Add the roles that you want to have privileges to define news items.

- Delete any roles you do not want to have the ability to define news items.

5. Connect to SQL*Plus.

6. Run the SQL script to process your changes:
START opapb_level_privs_m1.sql

Note:
Oracle supports this modification, but you are responsible for re-applying any modification if a patch overrides the package.

9.3 Creating and Modifying News Items

For each news item, you can:

- Define who sees the news item. You can determine who sees the news item based on a study, a site within the study, a user login name, or a user role.

- Set the dates for when to display the news item.

- Set the priority and sequence of the news item.

- Create a news headline. RDC displays the headline as a link in the News section on the Home page.

- Specify additional details about the news item. When the user clicks the headline link, RDC opens the News Details window, which displays the additional information you entered.

- Specify a link name (button label) and URL that RDC also displays in the News Details window.

9.3.1 Accessing the Form for Defining News Items

To access the form for defining news items:

1. Open the RDC Administration application.

2. Navigate to RDC Admin, Maintain, and then select News.
The system opens the News Definition for Remote Data Capture form. See Figure 9-2.

Table 9-1 describes the fields in the News Definition for Remote Data Capture form.

Figure 9-2 News Definition for Remote Data Capture Form

Table 9-1 Fields in the News Definition for Remote Data Capture Form

Field Name

Description

Study

Specifies the name of the study for which you want to make the news item available. To specify all studies, enter % (percent sign).

Site

Specifies the name of the site for which you want to make the news item available. The site must be in the specified study.

To specify all sites in the specified study, enter % (percent sign). If you specify % in the Study field, then you must specify % in the Site field.

User

Specifies the user name to which you want to make the news item available. To specify all users, enter % (percent sign).

Role

Specifies the role to which you want to make the news item available. To specify all roles, enter % (percent sign).

From Date

Specifies the date (inclusive) to start displaying the news item.

To Date

Specifies the date (inclusive) to stop displaying the news item.

Priority

Defines the importance ranking for the news item. Priorities range from 1 (highest) to 9 (lowest).

Use the Priority field, along with the Seq# field, to order the display of the news items. See Section 9.3.2, "Priority and Sequence of News Items" for more information.

Seq#

Defines the sequence, or placement, order of the displayed news items. The sequence value is either 1 or 2.

Use the Seq# field, along with the Priority field, to order the display of the news items. See Section 9.3.2, "Priority and Sequence of News Items" for more information.

Title

Specifies the headline text of the news item. RDC uses this text in the following places:

- For the link that displays in the News section on the Home page

- For the News title that displays in the News Details window

See Figure 9-1 for an example.

News

Provides the detail content of the news item. RDC displays this information in the News Details window.

You can specify one or more substitution parameters to customize and personalize news items. See Section 9.3.3, "Substitution Parameters for News Items" for more information.

Button

Provides a text label for the link that RDC displays in the News Details window.

URL

Specifies the URL that RDC displays in the News Details window. Users can click the URL to link to additional information.

9.3.2 Priority and Sequence of News Items

RDC supports an unlimited number of news items.

The order in which each news item is processed is based on a hierarchy that determines which item takes precedence:

- Priority

- Seq#

- Records where % is specified in the User field are listed before records where the user is specified

- Records where % is specified in the Study field are listed before records where the user is specified

- Records where % is specified for the Site field are listed before records where the user is specified

9.3.3 Substitution Parameters for News Items

You can add substitution parameters to the News field in the News Definition for Remote Data Capture form.

These parameters track variable information such as time of day, system date, first names, and last names. You can use these parameters to customize news items. For example, you can create personalized greetings based on the time of day and the user's last name: Good morning, Mr. Smith.

Table 9-2 lists the parameters that you can use when defining news text. For a sample of before and after text using these parameters, see Example 9-1.

Table 9-2 Substitution Parameters for News Items

Parameter

Description

Possible Value

Sample Usage

Displayed As

\TIME OF DAY\

Time according to the Application Server clock

12 midnight to 12 noon

Good\TIME OF DAY\

Good morning

less than 6 PM

Good\TIME OF DAY\

Good afternoon

6 PM to 12 midnight

Good\TIME OF DAY\

Good evening

\SYSDATE\

System date of the Application Server

18-Dec-2010

Today is \SYSDATE\

Today is 18-Dec-2010

\DAYS TO dd-mmm-yyyy\

Calendar days, not inclusive

15

New study begins in \DAYS TO 1-Oct-2009\ days.

New study begins in 18 days.

\FIRST NAME\

User's given name, from Oracle Accounts form

John

Hello \FIRST NAME\

Hello John

\LAST NAME\

User's surname, from Oracle Accounts form

Doe

Welcome to Oracle, Mr. \LAST NAME\.

Welcome to Oracle, Mr. Doe.

\NAME\

Full name (first name, last name, with initial capital letter)

John Doe

Hello, Mr. \NAME\!

Hello, Mr John Doe!

Example 9-1 Using the Substitution Parameters for News Items

Suppose you enter the following text and parameters in the News field in the News Definition for Remote Data Capture form:

Good \TIME OF DAY\, \FIRST NAME\. Today is \SYSDATE\. Bonus program for this quarter includes certificates for travel, entertainment, and electronics. See our Web site for details. You have \DAYS TO 31-DEC-2009\ days to earn rewards. Good luck!

RDC processes the parameters, substitutes the appropriate text, and displays the following message in the News Details window:

Good afternoon, Jane. Today is 3-Dec-2009. Bonus program for this quarter includes certificates for travel, entertainment, and electronics. See our Web site for details. You have 28 days to earn rewards. Good luck!

9.4 Querying News Definitions

In the RDC Administration application, you can also navigate to Query and then select News to access the News Definition for Remote Data Capture form in query mode. This option lets you access and view — but not add or modify — news items that are defined for studies in the database.

10 Customizing Activities

In Remote Data Capture, the Home page displays an Activities section that presents the user with a list of customized tasks.

The Activities section provides a configured set of links that guide the user to certain tasks. The text of the activity and how the activity appears can be based on specific conditions, such as the presence of discrepancies.

This chapter includes the following topics:

- Section 10.1, "Displaying the Activities List"

- Section 10.2, "Default Activities for RDC"

- Section 10.3, "Key Concepts for Activities"

- Section 10.4, "Activities Database Tables"

- Section 10.5, "Activity Tags and Functions Included with Oracle Clinical"

- Section 10.6, "Creating and Maintaining Customized Activities"

- Section 10.7, "Creating an Activity Tag Function"

10.1 Displaying the Activities List

RDC automatically displays the Activities section on the left side of the Home page. You do not need to configure any setting to display the Activities list.

10.2 Default Activities for RDC

Table 10-1 lists the default activities included in RDC.

Table 10-1 Default Activities for RDC

Title of the Activity Link Displayed on the Home Page

Clicking the Activities link…

Condition for Display

Review n Active Discrepancies

Opens the Review Discrepancies page and

If there is at least one active discrepancy in the site with an active discrepancy for the current user

Review n Other Discrepancies

Opens the Review Discrepancies page and

If there is at least one other discrepancy in the site with an other discrepancy for the current user

Review non-blank CRFs ready for initial verification

Opens the Review CRFs page and

If there is at least one CRF entered for a site

Review non-blank CRFs ready for initial approval

Opens the Review CRFs page and

If there is at least one CRF entered for a site

Review Investigator comments

Opens the Review Investigator Comments page and

If there is at least one Investigator Comment entered for a patient

10.3 Key Concepts for Activities

This section describes the following concepts for activities:

- User Roles and Activities

- Types of Activities

- Scope of Activities

10.3.1 User Roles and Activities

You can define an activity for a user role, a set of user roles, or all roles. If you specify one or more roles, the activity is applicable only to users with one of the specified roles. For example, if an activity list is set up for the DM role, the activity list defined would come up for all users to whom the DM role is granted.

10.3.2 Types of Activities

Each activity is a pre-defined shortcut that RDC displays as a link. There are two types of activities:

- Procedure — A procedure activity executes the defined query, navigates to the appropriate RDC page, and displays only those patients or CRFs that meet your defined search criteria. You use this type of activity for procedure-based tasks.

- URL — A URL activity launches a browser instance, opens a new browser window, and automatically navigates to the Web page associated with the URL you specified. You use this type of activity for URL-based tasks.

10.3.3 Scope of Activities

For RDC, the activity scope determines the page navigation. You can define an activity to navigate to the Review CRFs page, the Review Discrepancies page, the Review Investigator Comments page, or a Web page.

Additionally, RDC always processes a procedure activity for the current site. Therefore, the scope does not define whether the activity is applicable to a specific study, site, or patient.

10.4 Activities Database Tables

To create and maintain activities list, you use the following database tables:

- The RDC_ACTIVITIES database table, which contains the setup information for all the activities defined for the RDC application

- The RDC_ACTIVITIES_TAGS database table, which contains the tags that call the functions that provide values for a text string, a display expression, or a URL

The sections that follow provide more information about each table.

10.4.1 RDC_ACTIVITIES Database Table

The Oracle Clinical RDC_ACTIVITIES database table contains the setup information for all the activities defined for the RDC application. You can add new activities, modify existing activities, and delete activities.

Each record (that is, row) in the RDC_ACTIVITIES database table defines the setup information for one activity. Note that the database table includes the default activities listed in Table 10-2.

Each field (that is, column) defines the values for an activity. Table 10-2 describes each column in the RDC_ACTIVITIES database table.

Table 10-2 RDC_ACTIVITIES Database Table

Column Name

Description

Type (Max Length)

USER_ROLE

Specifies for which user roles RDC displays the activity. Each user logging in to RDC is associated with only one role. You can use the user role to control which activities RDC displays when the user logs in to the application.

You can specify:

- One role

- Multiple roles (use a comma to separate roles)

- All roles (use the % wildcard character)

For example, assume you define the following activities and user roles:

- Activity 1: USER_ROLE = %

- Activity 2: USER_ROLE = DM

- Activity 3: USER_ROLE = DM, CRA, SITE

For this example, RDC displays:

- All three activities when the data manager (DM) logs in

- Only Activity 1 and Activity 3 when the CRA logs in

- Only Activity 1 when the investigator (INV) logs in

The user role is not the only value that controls when RDC displays an activity. The value defined in the DISPLAY_EXPR column defines the condition that must be meet for RDC to display the activity. See the DISPLAY_EXPR description later in this table for more information.

VARCHAR2 (50)

TEXT

Specifies the title of the activity. This is the title the user sees in the RDC application. Examples of title text:

- Show All My Open Discrepancies

- Review All Investigator Comments

- Go to the Oracle Web Site

You must specify the TEXT value in English. RDC currently only supports English.

The TEXT value can contain one or more tags. A tag provides variable information, such as the site name, a count of records, or a refer function. You use % signs to enclose a tag. For example, %OPEN_DISCREPS%.

When you specify a tag in the TEXT column, RDC processes the tag as follows:

- Locates the tag in the RDC_ACTIVITY_TAGS table

- Calls the function specified in the FUNCTION_NAME column in that table

- Replaces the tag with the value returned by the called function

For example, assume the TEXT column has the following line:

Show %OPEN_DISCREPS% Active Discrepancies for Site %CURR_SITE%

For this example, the resulting title in the RDC application might be:

Show 3 Active Discrepancies for Site ACME DRUG CO

You can also customize the return value of the function to take into account the applicable site.

VARCHAR2 (200)

ACTIVITY_ID

Provides a unique key for the activity.

Number (10)

ACTIVITY_TYPE

Defines the type of activity.

- P — Indicates that this is a procedure activity. Recall that a procedure activity executes the defined query, navigates to the appropriate RDC page, and displays only those patients/CRFs that meet your defined search criteria. You use this type of activity for procedure-based tasks.

- U — Indicates that this is a URL activity. Recall that a URL activity launches a browser instance, opens a new browser window, and automatically navigates to the Web page associated with the URL. You use this type of activity for URL-based tasks.

VARCHAR2 (15)

ACTIVITY_SCOPE

Defines the scope in which the activity is eligible for display. The possible values for ACTIVITY_SCOPE depend on your version of the RDC application.

For RDC (4.5.3 and later), ACTIVITY_SCOPE determines the page navigation. Because all activities in RDC are always processed for the current site, you do not need to define whether the activity is applicable to a specific study, site, or patient.

- RDC_ZF_CRF — Navigates to the Review CRFs page.

- RDC_ZF_DISCREP — Navigates to the Review Discrepancies page.

- RDC_ZF_INV — Navigates to the Review Investigator Comments page.

- RDC_ZF_LINK — Navigates to the Web page defined by the URL.

VARCHAR2 (15)

ACTIVITY_EXEC

Defines what task RDC executes when the user clicks the activity link. The value you specify depends on the type of activity you are creating.

If the ACTIVITY_TYPE is P, then the value in the ACTIVITY_EXEC column:

- Is the name of the procedure to call when the activity is executed. Procedures use standard variables to determine the current study, site, or patients. Therefore, tags are not necessary with procedures. Examples of procedures:
rdc_activity_std.process_open_discreps

RDC_ZF_surround_activity.LoadInvComments('All')

If the ACTIVITY_TYPE is U, then the value in the ACTIVITY_EXEC column is the URL. As shown in the following examples, you can use tags to make the URL sensitive to the context:

U = https://company.com/v_rsdir/study%CURR_STUDY%.htm
U = https://opa.apps.company.com/v_rsdir/rdcservlet?study=%CURR_STUDY%&site=%CURR_SITE%

For these URL examples, you must create the study specific Web pages or a servlet that accepts study and site as parameters. See Section 10.6, "Creating and Maintaining Customized Activities" for more information.

VARCHAR2 (200)

DISPLAY_EXPR

Defines the condition that determines whether RDC displays the activity link. You can enter no value (null) or you can specify a conditional display expression associated with the activity. The expression can include tags. The expression must return a true or false value.

Based on the value in the column, RDC determines whether to display the activity.

- If the value is null, RDC always displays the activity.

- If the value of the specified expression evaluates to true, RDC displays the activity.

- If the value of the specified expression evaluates to false, RDC does not display the activity.

You use the DISPLAY_EXPR column to suppress activities if no records match a specific condition. For example, you can define that RDC display a link to view all active discrepancies only if the number of open discrepancies is greater than zero (%OPEN_DISCREPS% > 0).

%BLANK_COUNT%>0

%OPEN_DISCREPS%>0

%ZF_OTHER_DISC%>0

%ZF_OPEN_DISC%>0

VARCHAR2 (200)

10.4.2 RDC_ACTIVITY_TAGS Database Table

The RDC_ACTIVITY_TAGS database table contains the tags that are defined in the system and the execution module (function name) that evaluates the tag.

Table 10-3 describes the column in the RDC_ACTIVITY_TAGS table.

Table 10-3 RDC_ACTIVITIES_TAGS Database Table

Column Name

Description

Type (Max Length)

ACTIVITY_TAG

Defines the tag that you can then specify in the following columns in the RDC_ACTIVITIES database table:

- TEXT

- ACTIVITY_EXEC

- DISPLAY_EXPR

When RDC finds a tag in a column, RDC then searches through the values in the ACTIVITY_TAG column looking for a match for the tag.

- Locates the tag in the RDC_ACTIVITY_TAGS table

- Calls the function specified in the FUNCTION_NAME column in that table

- Replaces the tag with the value returned by the called function

When each of these columns is parsed, if a TAG is found, the process searches this column to find the TAG match so that it can identify the code or substitution variable to display in place of the TAG. If a match is found, it processes the expression found in the FUNCTION_NAME column.

VARCHAR2 (15)

FUNCTION_TYPE

Defines the type of function specified in the FUNCTION_NAME column.

- F — Indicates the function is a user-defined function.

- S — Indicates the function contains search parameters. You use this type as a place holder for the search parameters (if they need to be brought up as part of the URL link).

- P — Indicates the function contains one of the following parameters: SITE, STUDY, or PATIENT. RDC sets the tag to the name to apply to the site, study, or patient. You cannot define new tags as parameter tags. The valid values are restricted to the name of the site, study, or patient.

VARCHAR2 (15)

FUNCTION_NAME

Defines either the name of the substitution variable or the name of the function in the system. Depending on the FUNCTION_TYPE value, the value in this column can be one of several types.

- If the FUNCTION_TYPE is F, then this column holds a database function, for example rdc_activity_std.open_discreps. See Function Activity Tags for examples of activity tags with a function type of F.

- If the FUNCTION_TYPE is S, then, this column holds a database function, e. g. RDC_ZF_surround_crf.getCrfsCountReadyForVerify passing required values for the function execution internally.

- If the FUNCTION_TYPE is P, then the only valid value is SITE. The tag gets the value of the current site being processed.

- If the FUNCTION_TYPE is T, then this value refers to a trigger.

VARCHAR2 (61)

10.5 Activity Tags and Functions Included with Oracle Clinical

Table 10-4 lists the default activity tags and the corresponding functions included with Oracle Clinical and configured to work with existing functions.

You can add records to the RDC_ACTIVITY_TAGS database table to point to a function you create or to a pre-existing function.

Table 10-4 Default Activity Tags and Corresponding Functions

Activity Tag

Function Name

Description

Valid For

ZF_OPEN_DISC

RDC_ZF_surround_discrep.getOpenDiscrep

Count of active discrepancies for the current context

RDC only

ZF_OTHER_DISC

RDC_ZF_surround_discrep.getOtherDiscrep

Count of other discrepancies for the current context

RDC only

CURR_ROLE

Rdc_user_activity_tags.getCurrRole

Role of the current user

All versions of RDC

CURR_SITE

Rdc_user_activity_tags.getCurrSite

Site in context

All versions of RDC

CURR_STUDY

Rdc_user_activity_tags.getCurrStudy

Study in context

All versions of RDC

10.6 Creating and Maintaining Customized Activities

As described in Table 10-1, RDC has a set of default activities.

By modifying the RDC_ACTIVITIES database table, which contains the setup information for all the activities defined for the RDC application, you can:

- Create and add new activities

- Modify an existing activity

- Copy an existing activity and then modify it to create a new activity

- Delete an activity

In addition, you can create an activity procedure.

10.6.1 Working with the RDC_ACTIVITIES Table

In SQL*Plus, use SELECT * FROM rdc_activities to find the values for columns in an existing table.

To use these values to create procedural or link activities:

1. Log in to the database server.

2. Execute opa_setup:
opa_setup database-name

3. Connect to SQL*Plus by entering:
sqlplus rxc/rxcpassword

4. Execute the below query to determine the maximum activity ID that exists in the database:
SELECT max (activity_id) FROM rdc_activities;

5. If this is a task-based (procedural) activity, use an existing activity procedure or create a new one as instructed in Section 10.6.2. If this is a link activity, set up the Web service referred to by the link, if necessary.

6. Create an insert script like the example below, copying the text, activity_scope, activity_type, activity_exec, and display_expr from the original activity that you want to replicate.
For example, enter:

INSERT INTO rdc_activities (ACTIVITY_ID, CREATION_TS, CREATED_BY, USER_ROLE, TEXT, ACTIVITY_SCOPE, ACTIVITY_TYPE, ACTIVITY_EXEC, DISPLAY_EXPR) VALUES (&activityid, sysdate, 'RXC', 'DM,CRA&userrole', 'Review %OTHER_DISCREPS% Other Discrepancies', 'PATIENT', 'P', 'rdc_activity_std.process_other_discreps', '%OTHER_DISCREPS%>0'); COMMIT;

7. When prompted for the activity ID, enter a value just greater than the maximum activity ID in the database or greater than 20,000. This is to avoid conflicts with the default activities shipped with Oracle Clinical.

8. When prompted for the user role, enter the role for which you want to create this activity.

10.6.1.1 Copying Activities

To copy an activity, you can use values from an existing activity to populate a new activity record and then modify the columns as appropriate.

For example, enter the following command in SQL*Plus, replacing <ID> with the ID of the activity you want to copy:

INSERT INTO rdc_activities (ACTIVITY_ID, CREATION_TS, CREATED_BY, USER_ROLE, TEXT, ACTIVITY_SCOPE, ACTIVITY_TYPE, ACTIVITY_EXEC, DISPLAY_EXPR) VALUES (&activityid, sysdate, CREATED_BY, USER_ROLE, TEXT, 'RDC_ZF_DISCREP', ACTIVITY_TYPE, ACTIVITY_EXEC, DISPLAY_EXPR) WHERE activity_id = <ID>; COMMIT;

10.6.1.2 Deleting Activities

To delete an activity, enter the following command, replacing <ID> with the ID of the activity that you want to delete:

DELETE FROM rdc_activities WHERE activity_id = <ID>;

Alternatively, you can update the user role to NONE, preventing the activity from being used. To do so, use the following command, replacing <ID> with the ID of the activity that you want to take out of use:

UPDATE rdc_activities SET user_role = 'NONE' WHERE activity_id = <ID>;

10.6.2 Creating an Activity Procedure

The activity_exec in the ACTIVITY_TAGS table specifies the activity procedure that gets executed immediately before a procedure-based activity (versus URL) is executed. The activity procedure is used to load query parameters before executing the query for a page.

To specify each search parameter and its value, use the following procedure:

rdc_zf_surround_activity.setSearchCondition (parameter,value)

For example, the following procedure retrieves only CRFs with a book ID of 123:

rdc_surround.setSearchCondition (BOOK_ID, 123)

Table 10-5 lists the parameters that you can specify in the search procedure. For examples, see the existing procedure specified in the ACTIVITY_EXEC column of rdc_activities where the scope is like %ZF%.

When creating a new activity procedure, create your own package instead of using the packages included with Oracle Clinical. See Doc ID 2151942.1 on My Oracle Support for details on use and examples.

Table 10-5 Parameters for the rdc_zf_surround_activitiy.setSearchCondition Procedure

Parameter

Description

Example/Possible Values

STUDY_ID

Study ID

24601

SITE_ID

Site ID

4501

DCI_BOOK_ID

DCI book ID

1000

PATIENT_FROM

Starting range value for the patient ID

F101

PATIENT_TO

Ending range value for the patient ID

F106

VISIT_ID

Visit ID

10001

DCI_ID

DCI ID

101

APPROVAL_STATUS

Approval status

NOT APPROVED/APPROVED

VERIFICATION_STATUS

Verification status

NOT VERIFIED/VERIFIED

PATIENT_BOOK_ID

Patient book ID

101

CRF_ENTRY_STATUS

CRF entry status

BLANK

RECEIVED

BATCH LOADED

PASS 1 COMPLETE

PASS 1 STARTED

PASS 2 COMPLETE

PASS 2 STARTED

PASS 1 OR 2 COMPLETE

PAT_DISC_STATUS

Patient discrepancy status

OTHER, ACTIVE

CRF_DISC_STATUS

CRF discrepancy status

OTHER, ACTIVE

DISC_STATUS

Discrepancy status

OTHER, ACTIVE

PATIENT_ENTRY_STATUS

Patient entry status

USED, NOT_USED

PATIENT_LIST

List of patient position IDs. Populated when you select a set of patients on the Home page or the Casebooks page, and then drill down.

Can hold up to 360 IDs.

100100, 100101

PATIENT_LIST1, PATIENT_LIST2, PATIENT_LIST3

Use these parameters in addition to PATIENT_LIST if you have more than 360 IDs. With these parameters, you can store an additional 360 IDs per parameter.

100100, 100101

CRF_LIST

List of received DCI IDs, up to 360 IDs.

450001, 4500013, 4500014

CRF_LIST1, CRF_LIST2, CRF_LIST3

Use these parameters in addition to CRF_LIST if you have more than 360 IDs. With these parameters, you can store an additional 360 IDs per parameter.

100100, 100101

REVIEW_TYPE

The name of the standard or custom review type.

DM_REVIEW

REVIEW_STATUS

The current review status of the CRF to be acted upon.

RQ

10.6.3 Adding Counts to Existing Activities

The following default activities do not include counts:

- Review CRFs ready for approval

- Review CRFs ready for verification

- Review Investigator Comments

You can, however, modify these activities to include counts. You can use existing activity_tags CRF_READY_VERI, CRF_READY_APP, or INV_COMMENTS.

To use these, update the applicable activity tags so the text includes %tag_name%. The following statements update:

Connect as RXC user
SQL*Plus> UPDATE rdc_activities SET title = 'Review  %CRF_READY_VERI% non-blank CRFs ready for initial verification' WHERE activity_id = 9528;
SQL*Plus> UPDATE rdc_activities SET title = 'Review  %CRF_READY_APP% non-blank CRFs ready for initial approval' WHERE activity_id = 9529;
SQL*Plus> UPDATE rdc_activities SET title = 'Review  %INV_COMMENTS% Investigator comments' WHERE activity_id = 9530;
SQL*Plus> COMMIT;

Note:
The Activity tags used in the above queries are existing tags referring to the function that limits to max 1000 rows, update the activity tag function or create a new activity tag referring to a new custom function, include the activity tag in the above query.

If you do not want to limit the count to 1,000, you will need to create your own function and create activity tag records to refer to these functions. The code for the function should be as follows:

FUNCTION <name> RETURN NUMBER
IS
nCount NUMBER(10);
nClinicalStudyId NUMBER(10);
nSiteId NUMBER(10);
BEGIN
nClinicalStudyId := rdc_daapi.getStudyId;
nSiteId := rdc_daapi.getSiteId;
<select statement from table below>;
RETURN ncount;
END;

The SQL statements in Table 10-6 will calculate the counts.

Table 10-6 SQL Statements to Calculate Counts

Count of…

SQL statement

CRFs Ready for Approval

SELECT /*+ index(rd RECEIVED_DCI_SITE_NFK_IDX) */  count(1)
INTO nCount
FROM received_dcis rd, patient_positions pp1
WHERE rd.patient_position_id = pp1.patient_position_id AND pp1.has_data_flag = 'Y'
AND pp1.clinical_study_id = nClinicalStudyId
AND rd.end_ts = to_date(3000000,'J')
AND rd.clinical_study_id = nClinicalStudyId
AND rd.site_id = nSiteId
AND rdc.rdci_verify_status(RDC_ZF_surround.fetchMode,RD.received_dci_id) = 'VERIFIED'
AND rdc.rdci_verify_status(RDC_ZF_surround.fetchMode,RD.received_dci_id) = 'VERIFIED'
AND rdc_daapi.hasDiscrep(rd.received_dci_id,'NONE')='Y' AND decode(RD.received_dci_status_code,'PASS 1 COMPLETE',1,'PASS 2 STARTED',1,'PASS 2 PENDING',1,'PASS 2 COMPLETE',1,0) = 1

CRFs Ready for Verification

SELECT /*+ index(rd RECEIVED_DCI_SITE_NFK_IDX) */  count(1)
INTO nCount
FROM received_dcis rd, patient_positions pp1
WHERE rd.patient_position_id = pp1.patient_position_id
AND pp1.has_data_flag = 'Y'
AND pp1.clinical_study_id = nClinicalStudyId
AND rd.end_ts = to_date(3000000,'J')
AND rd.clinical_study_id = nClincalStudyId
AND rd.site_id = nSiteId
AND decode(rdc.rdci_verify_status(RDC_ZF_surround.fetchMode,RD.received_dci_id),'NOT VERIFIED',1,'UNDONE',1,0) = 1
AND rdc_daapi.hasDiscrep(rd.received_dci_id,'NONE')='Y' AND decode(RD.received_dci_status_code,'PASS 1 COMPLETE',1,'PASS 2 STARTED',1,'PASS 2 PENDING',1,'PASS 2 COMPLETE',1,0) = 1

Investigator Comments

SELECT /*+ index(pp1 PATIENT_POSITION_PK_IDX)
index(rd RECEIVED_DCI_PK_IDX)
index(respX RESPONSE_PK_IDX)
index(rdcmX RECEIVED_DCM_PK_IDX)*/ count(1)
INTO nCount
FROM responses respX,received_dcms rdcmX,received_dcis rd,patient_positions pp1
WHERE dcmX.RECEIVED_DCM_ID = respX.RECEIVED_DCM_ID
AND respX.clinical_study_id = nClinicalStudyId
AND rdcmX.end_ts = to_date(3000000,'J')
AND rd.end_ts = to_date(3000000,'J')
AND rd.received_dci_id = rdcmX.received_dci_id
AND pp1.patient_position_id = rd.patient_position_id
AND respX.end_ts = to_date(3000000,'J')
AND pp1.clinical_study_id = nClinicalStudyId
AND rd.site_id = nSiteId
AND respX.data_comment_text is not null

10.7 Creating an Activity Tag Function

If the existing activity tags do not provide what you are looking for, you can create a new activity tag and corresponding activity tag functions. You should create your own package and not use those packages included with Oracle Clinical.

Activity tag functions commonly execute a SQL statement to count the applicable activity.

If the activity count causes performance problems, there are various ways to improve performance if tuning the specific SQL statement does not work. You can limit the count to first 1,001 rows, and return >1,000 if more than 1,000. If two activities require processing a similar set of records, you could calculate two counts simultaneously, return the first count, and buffer the second count. The function for the second activity could return the buffered value. This technique requires that the activities are displayed in a specific order.

Table 10-7 lists the functions included in the RDC_USER_ACTIVITY_TAGS package that you can use in your activity tag function.

Table 10-7 Functions Included in the RDC_USER_ACTIVITY_TAGS Package

Functions

Description

ANY_DISCREPS

Populates the activity with patients/CRFs having the type of discrepancy passed as parameter: ACTIVE/OTHER.

ENFORCEREQUERY

Force refreshes the results returned by the activity.

NEXT_PATIENT

Returns the next available unused patient position in the study.

OPEN_DISCREPS

Populates the activity with patients/CRFs having ACTIVE discrepancies.

OTHER_DISCREPS

Populates activity with patients/CRFs having OTHER discrepancies.

PATIENT_DATA

Returns all if the current patient in context has data and new if the patient doesn't have data entered.

PAT_STATUS_ICON

Returns blank if the current patient in context has no data, red patient if the patient has active discrepancies, yellow patient if the patient has other discrepancies, and white patient if the patient data has no discrepancies.

PROCESS_CURR_PATIENT

Adds the current site and patient in context to the activity query built.

PROCESS_CURR_SITE

Adds the current site (or the passed site) to the activity query built.

PROCESS_CURR_STUDY

Resets the site to ALL, to process the activities query for all the sites in the study.

PROCESS_NEXT_PATIENT

Sets the site passed to the activities search context, fetches the next available patient, and sets the next available patient also in context.

PROCESS_OPEN_DISCREPS

Assigns the site passed (if any) to the activity search context and sets the activity to search for ACTIVE discrepancies. Also, sets the current patient (if set) to the search context.

PROCESS_OTHER_DISCREPS

Assigns the site passed (if any) to the activity search context and sets the activity to search for OTHER discrepancies. Also, sets the current patient (if set) to the search context.

FILTERINCLUDESPATIENT

Returns flag that indicates if patients are included in the activity search.

RESETINCLUDESPATIENT

Sets flag that indicates if patients are to included in the activity search to TRUE to improve the performance of the activity queries.

SETINCLUDESPATIENT

Sets flag that indicates if patients are to included in the activity search to FALSE. Also, to improve the performance of the activity queries.

11 Configuring Links

You can use the Maintain Links form in the RDC Administration application to add customized links to RDC. Any information that can be made available through a URL can be made accessible to RDC users.

In addition, your customized links support passing session details to a URL or database function. Therefore, you can link to pages that are context-sensitive to a user's current RDC environment.

For example, you can configure a URL that RDC displays in the Links section on the Home page. The link adds a parameter string with the session's user role value to the URL. You can write a target page that switches the content according to user role. A site user, data manager, and investigator can then view different content from the same link.

This chapter includes the following topics:

- About Custom Links

- Using the Maintain Links Form

- Link Parameters

- Creating Links for the Home Page

- Defining Links for the Patient Summary Reports

- Defining a Link for CRF Help

11.1 About Custom Links

In the Maintain Links form, you can customize links that display in the RDC application. You can define links for:

- The Links section on the Home page

- The Links section in a Patient Summary Report

- The CRF Help icon when viewing and updating a CRF in the Data Entry window

When you create these links, you can restrict the audience for the link. You can define who has access to the link and the associated Web page. Access can range from no restriction (for all users) to very restricted access (for users with a certain role only).

Note:
You do not configure other custom links, such as a News link or an Activity link, in the Maintain Links form. For more information on customizing those links, see Chapter 9, "Configuring News" and Chapter 10, "Customizing Activities."

11.1.1 Links on the Home Page

In RDC, the Links section on the Home page displays your customized links to other Web sites or applications. See Figure 11-1. The Home page supports an unlimited number of links. You can also change the title of the Links section.

Figure 11-1 Sample Customized Links on the Home Page

11.1.2 Links on the Patient Summary Report

RDC lets you display a maximum of three patient links in the Links section of a Patient Summary Report. See Figure 11-2.

In a typical patient link, RDC passes parameters to a custom SQL program and opens a new browser window. The custom program queries the database for patient data and presents a custom report in the new browser window.

Figure 11-2 Links Displayed in the Patient Summary Report

11.1.3 A Link for CRF Help

You can configure one link for the CRF Help icon in the toolbar in the Data Entry window. When the user clicks the icon, RDC opens a new browser window to the link's target location. RDC displays the CRF Help icon only if you define and enable a link in the Maintain Links form.

Figure 11-3 Customizing Help for the CRF

11.2 Using the Maintain Links Form

To access the Maintain Links form:

1. Log in to the RDC Administration application.

2. Select Maintain, and then select Links.

Figure 11-4 shows the Maintain Links form.

Figure 11-4 Maintain Links Form

11.2.1 Ordering the Display of Links

Use the Seq# field to specify the order in which a link appears in its section in RDC. The value for each Seq# must be unique for all links that appear in RDC.

11.2.2 Defining the Link Text

Use the Link Text field to specify the text for the link label.

RDC uses this text when listing the links on the Home page and in the Patient Summary Report.

11.2.3 Specifying the URL or Function

Use the URL field to specify either the URL or the function name, depending on whether you are creating a static link or a dynamic link:

- For a static link, enter the URL of the target Web page. The URL must work when RDC appends the parameters listed in Table 11-2, even if you do not take advantage of the parameters.

- For a dynamic link, enter the specification for the function. The function must handle the parameters specified in Table 11-3.

11.2.4 Specifying the Type of Link

Use the Type field to specify the type of link you are creating. You can define two type of links for use in the RDC application:

- Static links

- Dynamic links

Both types of links support passing parameter values to a URL. Therefore, you can link to pages that are context-sensitive to a user's current RDC environment.

The two types of links differ in the way RDC generates the URLs.

For static links, RDC appends a parameter string of session information to the target URL you specified in the URL field. You must write a target URL page, such as a JavaServer page, that can process the parameters. Note that for a static link with a scope of None, RDC passes a URL without a parameter string.

For dynamic links, RDC derives the URL from the return value of the database function you specified in the URL field. The database function also takes parameters. You must create the target URL page. Dynamic links trigger your own functions to return URLs.

11.2.5 Specifying the Link Scope

The scope of a link determines two factors: where RDC displays the link and which parameter values RDC passes to either the URL or the function.

- Links of scope None, User, Study, and Site display in the Links section on the Home page. The Home page supports an unlimited number of links.

- Links of scope Patient display in the Links section of a Patient Summary Report. You can define a maximum of three links to display in a Patient Summary Report. In the Maintain Links form, you select the Use Pt/CRF Link in Onsite check box to mark up to three links to display in the Patient Summary Report.

- A link of scope CRF configures a link for the CRF Help icon in a Data Entry window. In the Maintain Links form, you select the Pt/CRF Link in Onsite check box for one link.

11.2.6 Enabling Patient Summary and CRF Help Links

The Use Pt/CRF Link in Onsite check box applies only to links of scope CRF or Patient.

RDC lets you display a maximum of three patient links in a Patient Summary Report. It lets you define one link for the CRF Help icon in a Data Entry window.

To specify which patient and CRF links appear in RDC, select the Use Pt/CRF Link in Onsite check box for the appropriate links.

11.3 Link Parameters

Table 11-1 describes all the possible parameters for static links and dynamic links. The scope of a link defines the subset of these parameters that RDC appends to your specified URL or passes to your specified function.

Table 11-1 Parameter Descriptions

Static Links Parameter Name

Dynamic Links Parameter Name

Database Object

Description

userid

pUserId

USERID

Sends the login user ID of the RDC session.

user_role

pUserRole

USER_ROLE

Sends the RDC login user's assigned role value.

test_prod

pTestProd

TEST_PROD

Sends the session's study mode: T for Test mode or P for Production mode.

study_id

pStudyId

CLINICAL_STUDY_ID

Sends the internal Oracle Clinical identifier that corresponds to the STUDY value.

study

pStudy

STUDY

Sends the session's Oracle Clinical Study name.

site_id

pSiteId

SITE_ID

Sends the internal Oracle Clinical identifier that corresponds to the SITE value.

site

pSite

SITE

Sends the session's SITE value.

patient_id

pPatientId

PATIENT_POSITION_ID

Sends the internal Oracle Clinical identifier that corresponds to the PATIENT value.

patient

pPatient

PATIENT

Sends the name of the PATIENT the user is currently viewing.

book_id

pBookId

DCI_BOOK_ID

Sends the internal identifier that corresponds to DCI_BOOKS.NAME.

book

pBook

DCI_BOOKS.NAME

Sends the name of the DCI book the user is currently viewing.

dci_id

pDciId

DCI_ID

Sends the internal Oracle Clinical identifier that corresponds to the user's currently viewed DCI.

cpe_id

pCpeId

CLIN_PLAN_EVE_ID

Sends the internal Oracle Clinical identifier that corresponds to the user's currently viewed Clinical Planned Event.

subno

pSubNo

SUBEVENT_NUMBER

Sends the subevent number.

page_display_sn

PPageDisplaySn

DISPLAY_SN

Sends the DCI's sequence number, its viewing order in the currently viewed DCI Book. DISPLAY_SN is in the DCI_BOOK_PAGES table.

page_no

pPageNo

—

Sends the derived page number in the currently viewed Data Entry window of a multiple-page DCI.

—

pHeader

—

Sends the value of the URL field. This value is used in earlier RDC releases. It is available in dynamic links but not in static links.

—

pScope

—

Sends the scope type to a dynamic link function. It is available in dynamic links but not in static links.

11.3.1 Parameters for Static Links Based on Scope

Static links generate a URL from the target HTTP address defined in the Maintain Links form. Based on the scope of the link, RDC appends a subset of parameter values from the user's current session to your specified URL when the user clicks the link.

You create a target Web page that can resolve the parameter values that RDC appends to the URL. You do not have to use all of the parameters, but the target page must be able to open the URL.

Table 11-2 lists the parameter strings that RDC appends to static links, according to the scope of the link.

Table 11-2 Parameter Strings for Static Links

Scope

Parameter String Appended to the URL Value

None

RDC appends no parameters to the URL value.

User

?user_role=user_role

Study

?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study

Site

?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study&site_id=site_id&site=site

Patient

?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study&site_id=site_id&site=site
&patient_id=patient_id&patient=patient

CRF

?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study&site_id=site_id&site=site
&patient_id=patient_id&patient=patient&book_id=book_id
&book=book&dci_id=dci_id&cpe_id=cpe_id&subno=subno
&page_display_sn=page_display_sn&page_no=page_no

11.3.2 Parameters for Dynamic Links Based on Scope

Dynamic links derive an HTTP address from a function. You create a function that returns a URL.

Table 11-3 lists the parameters that RDC passes to a SQL function, according to the scope of the link. All parameters are VARCHAR2 except for the pStudyId and pSiteId parameters, which are NUMBER.

Table 11-3 Dynamic Link Parameters

Scope

Parameters Passed to the SQL Function

None

pHeader, pScope

User

pHeader, pScope, pUserRole

Study

pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy

Site

pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy, pSiteId, pSite

Patient

pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy, pSiteId, pSite, pPatientId, pPatient

CRF

pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy, pSiteId, pSite, pPatientId, pPatient, pBookId, pBook, pDciId, pCpeId, pSubNo, PPageDisplaySn, pPageNo

Note:
The Maintain Links form does not verify the existence of, validity of, or access privileges to functions or data.

11.3.2.1 Sample Function Available

Oracle provides the following sample function that you can use when defining links:

dmo_links.geturl

This function is in the rxcpbdmolinks.sql file, which is located in the INSTALL directory.

11.3.2.2 Function Specification for Dynamic Links

The following specification outlines the requirements of the function that is accessed by dynamic links with a scope of CRF.

Note:
A dynamic link with a scope of CRF processes all available session parameters. You can specify functions for dynamic links of other scopes with fewer parameters, but if you use DEFAULT NULL then you can include the extra parameters.

Create or replace FUNCTION sub-program name here(
, pHeader        IN VARCHAR2 DEFAULT NULL
, pScope         IN VARCHAR2 DEFAULT NULL
, pUserId        IN VARCHAR2 DEFAULT NULL
, pUserRole      IN VARCHAR2 DEFAULT NULL
, pTestProd      IN VARCHAR2 DEFAULT NULL
, pStudyId       IN VARCHAR2 DEFAULT NULL
, pStudy         IN VARCHAR2 DEFAULT NULL
, pSiteId        IN VARCHAR2 DEFAULT NULL
, pSite          IN VARCHAR2 DEFAULT NULL
, pPatientId     IN VARCHAR2 DEFAULT NULL
, pPatient       IN VARCHAR2 DEFAULT NULL
, pBookId        IN VARCHAR2 DEFAULT NULL
, pBook          IN VARCHAR2 DEFAULT NULL
, pDciId         IN VARCHAR2 DEFAULT NULL
, pCpeId         IN VARCHAR2 DEFAULT NULL
, pSubNo         IN VARCHAR2 DEFAULT NULL
, PPageDisplaySn IN VARCHAR2 DEFAULT NULL
, pPageNo        IN VARCHAR2 DEFAULT NULL
)RETURN VARCHAR2 IS
BEGIN sub-program logic here
END;

11.4 Creating Links for the Home Page

Links of scope None, User, Study, and Site display in the Links section of the RDC Home page.

The Home page in RDC displays your customized links in the Links section. The Home page supports an unlimited number of links. You can also change the name of the Links section.

Links on the Home page can have one of the following scopes:

- None — Use this scope to create a link with no parameter information from the user's session. For example, you can create a link to your company's home page.

- User — Use this scope to generate links targeted to user roles.

- Study — Use this scope to generate links to study-specific content.

- Site — Use this scope to generate links to site-specific content.

Table 11-1 describes all the possible parameters for static links and dynamic links. For static links, see Table 11-2 for a list of parameter values that RDC appends to your specified URL based on the scope of the link. For dynamic links, see Table 11-3 for a list of parameter values that RDC passes to your specified function based on the scope of the link.

11.4.1 Defining a Link for the Home Page

To define a link for the Links section on the Home page:

1. Log in to the RDC Administration application.

2. Select Maintain, and then select Links.

3. Insert or modify a row in the Maintain Links form to have these settings:

- Seq# — Sequence the rows so they have the same sequence that you prefer in the Links section on the Home page.

- Link Text — Enter the link label. RDC uses your specified text when listing the links in the Links section on the Home page.

- URL — Enter the URL if you are defining a static link; enter the name of the function if you are defining a dynamic link.

- Type — Select either Static or Dynamic. (See Section 11.2.4, "Specifying the Type of Link" for more information.)

- Scope — Select None, User, Study, or Site. The scope determines which parameter values RDC passes to either the URL or the function.

- Use PT/CRF Link in Onsite — Do not enable this setting. This setting applies only to links of scope CRF or Patient.

4. Save your changes.

5. Create a target Web page that can resolve the parameters RDC passes when the user invokes the link.

11.4.2 Parameters for Links with a Scope of None

Use scope type None to create a link with no parameter information from the user's session.

- For a static link of scope None, RDC does not append a parameter string to the URL.

- For a dynamic link of scope None, RDC passes the following parameter values to the function:
pHeader, pScope

11.4.3 Parameters for Links with a Scope of User

Use scope type User to generate links targeted to user roles.

- For a static link of scope User, RDC appends the following parameter values from the user's session to the URL:
?user_role=user_role

- For a dynamic link of scope User, RDC passes the following parameter values from the user's session to the function:
pHeader, pScope, pUserRole

See Table 11-1 for a description of each parameter.

Example 11-1 Creating a Dynamic User Link

Sample steps to create a dynamic user link:

1. Insert a row into the Maintain Links form.

2. Specify the following values:

- URL: dynamicUrl.getUsersUrl

- Type: Dynamic

- Scope: User

3. Create a SQL function named getUsers in package dynamicUrl with the following specification:
function getUsers (pHeader varchar2, pScope varchar2, pUserRole varchar2)
return varchar2

4. Write the return clause of the function to return a URL.

11.4.4 Parameters for Links with a Scope of Study

Use scope type Study to generate links to study-specific content.

- For a static link of scope Study, RDC appends the following parameter values from the user's session to the URL:
?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study

- For a dynamic link of scope Study, RDC passes the following parameter values from the user's session to the function:
pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy

See Table 11-1 for a description of each parameter.

Example 11-2 Static Study Link

Configure a static link of scope Study for the following URL:

https://mycompany.com/study.jsp

If the data manager PRASPADM is viewing the PILOT study, which is in production, RDC generates the following URL:

https://mycompany.com/study.jsp?userid=PRASPADM&user_role=DM&test_prod=P&study_id=28601&study=PILOT

11.4.5 Parameters for Links with a Scope of Site

Use scope type Site to generate links to site-specific content.

- For a static link of scope Site, RDC appends the following parameter parameter values from the user's session to the URL:
?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study&site_id=site_id&site=site

- For a dynamic link of scope Site, RDC passes the following parameter values from the user's session to the function:
pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy, pSiteId, pSite

See Table 11-1 for a description of each parameter.

Example 11-3 Static Site Link

Configure a static link of scope Site for the following URL:

https://mycompany.com/site.jsp

If the data manager JSMITH at site 001 is running a session in the PDFREPORT study, which is in production, RDC generates the following URL:

https://mycompany.com/site.jsp?userid=jsmith
&user_role=dm&test_prod=P&study_id=55202&study=pdfreport
&site_id=4501&site=001

11.4.6 Customizing the Label for the Links Section

The Label for the Links Tab configuration setting lets you customize the title of the Links section on the Home page. For example, you may want to change the title to More Study Information or Helpful Web Sites.

For more information on customizing the label, see Section 3.3, "Configuration Settings for RDC."

11.5 Defining Links for the Patient Summary Reports

You can define a maximum of three links for the Links section of a Patient Summary Report. These links have a scope of Patient.

To define a link for the Patient Summary Report:

1. Log in to the RDC Administration application.

2. Select Maintain, and then select Links.

3. Insert or modify a row in the Maintain Links form to have these settings:

- Seq# — You can define up to three links for the Patient Summary Report. Sequence the Patient-scope rows so they have the same sequence that you prefer in the report's Links section.

- Link Text — Enter the link label.

- URL — Enter the URL if you are defining a static link; enter the name of the function if you are defining a dynamic link.

- Type — Select either Static or Dynamic. (See Section 11.2.4, "Specifying the Type of Link" for more information.)

- Scope — Select Patient.

- Use PT/CRF Link in Onsite — Enable this check box. You can select up to three rows with a scope of Patient.

4. Save your changes.

5. Create a target Web page or JavaServer page referred to by the static URL, or the dynamic return value of the function you specified.

11.5.1 Parameters for a Patient Link

Use scope type Patient to create links for the Patient Summary Report.

- For a static link of scope Patient, RDC appends the following parameter values from the user's session to the URL:
?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study&site_id=site_id&site=site
&patient_id=patient_id&patient=patient

- For a dynamic link of scope Patient, RDC passes the following parameter values from the user's session to the function:
pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy, pSiteId, pSite, pPatientId, pPatient

See Table 11-1 for a description of each parameter.

Example 11-4 Static Patient Link

Configure a static link of scope Patient for the following URL:

https://mycompany.com/patient.jsp

When data manager JSMITH, who is viewing patient 101 of in-production study PDFREPORT at site 001, clicks on the link in the Patient Summary Report, RDC invokes the following URL:

https://mycompany.com/patient.jsp?userid=jsmith
&user_role=dm&test_prod=p&study_id=28601&study=pdfreport
&site_id=4501&site=001&patient_id=100001&patient=101

11.6 Defining a Link for CRF Help

You can configure one link for CRF Help. If you configure this link, RDC automatically adds the CRF Help icon to the toolbar in the Data Entry window.

Clicking the icon opens a new browser window to the link's target location and displays sponsor-defined help for the current CRF.

The link for CRF Help has a scope of CRF. The link can be static or dynamic.

To configure a link for CRF Help:

1. Log in to the RDC Administration application.

2. Select Maintain, and then select Links.

3. Insert or modify a row in the Maintain Links form to have these settings:

- Seq# — Not relevant because you can define only one link for CRF Help.

- Link Text — Not relevant because RDC adds the CRF Help icon to the toolbar.

- URL — Enter the URL if you are defining a static link; enter the name of the function if you are defining a dynamic link.

- Type — Select either Static or Dynamic. (See Section 11.2.4, "Specifying the Type of Link" for more information.)

- Scope — Select CRF.

- Use PT/CRF Link in Onsite — Enable this check box. You can select only one row for a CRF link.

4. Save your changes.

5. Create a target Web page or JavaServer page referred to by the static URL, or the dynamic return value of the function you specified.

11.6.1 Parameters for a CRF Help Link

Use scope type CRF to create a link to the CRF Help.

- For a static link of scope CRF, RDC appends the following parameter values from the user's session to the URL:
?userid=userid&user_role=user_role&test_prod=test_prod
&study_id=study_id&study=study&site_id=site_id&site=site
&patient_id=patient_id&patient=patient&book_id=book_id
&book=book&dci_id=dci_id&cpe_id=cpe_id&subno=subno
&page_display_sn=page_display_sn&page_no=page_no

- For a dynamic link of scope CRF, RDC passes the following parameter values from the user's session to the function:
pHeader, pScope, pUserId, pUserRole, pTestProd, pStudyId, pStudy, pSiteId, pSite, pPatientId, pPatient, pBookId, pBook, pDciId, pCpeId, pSubNo, pPageDisplaySn, pPageNo

See Table 11-1 for a description of each parameter.

11.7 Querying Link Definitions

In the RDC Administration application, you can also navigate to Query and then select Links to access the Maintain Links form in query mode. This option lets you access and view — but not add or modify — the links that are defined for RDC.

11.8 About Storing Your Customized Web Pages

See Section 7.11, "Storing Custom Web Pages" for more information on where to place your Web pages.

12 Customizing Online Help

You can customize the help that users can display when using the RDC application. You can create help text for each field in a CRF, modify the existing online help topics installed with RDC, and create help information for CRFs displayed in the Data Entry window.

This chapter includes the following topics:

- Defining Help for the Fields in a CRF

- Customizing Online Help

- Defining Help for CRFs

12.1 Defining Help for the Fields in a CRF

When using RDC to enter and update data in a CRF, users can right-click a field and select Field Help to get more information about the field.

RDC opens the Oracle Clinical Data Collection Help window, which displays the help text for the field's DCM Question Group, the help text for the selected field, and other details. See Figure 12-1.

To define this field-level help, you add text to the Oracle Clinical data collection definitions.

Figure 12-1 Custom Help Text for Fields in a CRF

You can enter CRF field help text in Oracle Clinical at the study level for:

- DCM question groups

- Individual DCM questions within a group

Note:
You can define help text for active or provisional DCMs only.

To enter help text for a DCM question group and its DCM questions:

1. Open Oracle Clinical.

2. Navigate to Definition, DCMs, and then select DCMs.

3. Select the study where you are defining help text. The Maintain Study DCMs form opens.

4. Select a DCM and then click DCM Question Groups. The DCM Question Groups form opens, listing the question groups that are part of the study's DCM.
To define help text for a DCM question group:

1. Select a question group.

2. Scroll to the right until you view the Help Text field.

3. Enter up to 200 characters of text.

To define help text for an individual question in a DCM question group:

1. Select a question group.

2. Click DCM Questions. The DCM Questions form opens, displaying the individual questions that comprise the question group.

3. Scroll to the right until you view the Help Text field.

4. Enter up to 200 characters of text.

5. Save your changes and regenerate the CRF.

12.2 Customizing Online Help

RDC includes context-sensitive online help files that describe using the application's features. Users invoke the online help by clicking the Help link or button displayed on the application pages, in the Data Entry window, or in a dialog box.

The online help includes several navigation frames and a large content frame that displays the contextual topics. The topic files are in HTML format and are generated from the Oracle Clinical Remote Data Capture User's Guide content. You can customize a copy of the online help files and redirect RDC to display your copy.

Note:
The online help is dynamically generated and changes may not be consistent between generations. Oracle does not document changes to the structure or content of the online help between upgrades. If you customize the online help, you may have to reconcile your changes after installing a patch or an upgrade. Release notes indicate if the patch or upgrade affects the online help.

The tasks required to customize the RDC online help are as follows:

- Copying the RDC Help Files

- Identifying Individual Topic Files

- Modifying the Topic Text

- Diverting the Help Call to a Custom Location

12.2.1 Copying the RDC Help Files

The online help files for RDC are bundled within the olsardc.ear and are extracted on deployment in a location like:

middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc\5.x-b2\app\olsardc.ear\RdcSurroundAdfWebUIWebApp.war\xhelp\rdc\footprint\

Above, the x in 5.x represents the minor release version of the application that is currently installed.

To edit the contents of the archive, you need to open it and add files to the package, as sown in the following steps.

1. Log in to the administrator server console for the OPA domain and locate the olsardc.ear file. See "Locating the olsardc.ear File" for more information.

2. Open the olsardc.ear file using any utility to unzip.

Note:
Also see "Manually Extracting and Repacking the olsardc.ear File" for an alternative method to unzip and rebuild the EAR file.

3. Edit the web.xml file to divert the call to the new location of the help files. See "Diverting the Help Call to a Custom Location" for instructions.
The context-sensitive help calls from RDC require the directory structure for your customized online help to match the help directory structure provided within RDC.

You can locate your custom help directory on the shared drive of another application server, but the new location must be accessible by URL.

4. Navigate to the following path:

middleware_home\user_ projects\domains\OPADomain\servers\AdminServer\upload\olsardc\5.x-b2\app\olsardc.ear

5. Add or edit help files as required.

6. Save your changes.

7. Redeploy olsardc.ear.
See "Redeploying RDC with Customizations" for more information.

8. Restart the OPA server.
See "Restarting the OPA Server" for more information.

Note:
Do not place your custom help directory in the same directory where the Oracle-provided online help is installed:
middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc\5.x-b2\app\olsardc.ear\RdcSurroundAdfWebUIWebApp.war\xhelp\rdc\footprint\

The x in 5.x above represents the version of the application installed.

This directory may be overwritten by subsequent upgrades or patches.

12.2.2 Identifying Individual Topic Files

The RDC online help system does not use file names in its context calls. Therefore, the most reliable method for identifying a topic's file name is to invoke the topic from RDC and then open the Properties dialog box.

To identify the file name of a help topic:

1. Open RDC to the feature you are documenting.

2. Click Help to open the help topic in a new browser window.

3. Right-click the topic area of the window, and then select Properties.

4. Note the address listed in the Address (URL) field. The file name for the selected topic is located at the end of the URL address as filename.html. See Figure 12-2.

Note:
Be careful to immediately identify the topic file after you open it from RDC. If you use the help system's navigation aids to browse, you might open another topic file instead of the topic file you want to edit.

Figure 12-2 Identifying the File Name of Individual Help Topics

12.2.3 Modifying the Topic Text

To modify the text for an online help topic:

1. Navigate to the directory location of your customized online help files.

2. Open the file that you identified as the HTML file associated with the topic you want to modify.

3. Edit the text.

4. Save your changes.

When modifying a help topic, keep the following issues in mind to ensure that you retain RDC's context-sensitivity:

- Do not change header content, file names, anchors, or other metadata. The topic files include metadata identifiers for the context calls from RDC and for navigating and searching. Changing this metadata may break the context calls from the application or the system's navigation aids.

- Save the file with the same name and to the same relative location.

12.2.4 Diverting the Help Call to a Custom Location

When a user clicks Help in RDC, the application constructs a URL based on the current session and the default installation location of the online help system.

To divert the help call to the custom location you created in Section 12.2.1, you edit the OPA_DOC_DIR parameter in the web.xml file.

To divert the help call to a custom location:

1. Log into the admin server console for the OPADomain and locate the olsardc.ear file. See Section D.1, "Locating the olsardc.ear File" for more information.

2. Open olsardc.ear using any utility to unzip.

3. Navigate to the location of web.xml at the following path:

middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear\RdcSurroundAdfWebUIWebApp.war\WEB-INF\

4. Open the web.xml file with a text editor.

5. Insert the following lines in the file:
<context-param>
<param-name>OPA_DOC_DIR</param-name>
<param-value>%HTTP URL OF THE Custom Location%</param-value>
</context-param>

Note:
If you do not specify a location for the OPA_DOC_DIR parameter, RDC opens the topic files from the default installation location.

6. Replace %HTTP URL OF THE Custom Location% with the location of your customized online help files. The syntax of the location is as follows:
https://help-doc-hostname/directory-name/xhelp

For example, https://appserverurl/opa52/xhelp.

Note:
Do not add a slash (/) to the end of the URL. RDC adds a slash and several parameters to the URL to open the file.

7. Save your changes.

8. Click OK when prompted to replace the modified files in the .war and .ear. files

9. Close the unzip utility.

10. Redeploy the olsardc.ear file and then restart the OPA server for the changes to take effect.
See Section D.4, "Redeploying RDC with Customizations" for instructions.

12.3 Defining Help for CRFs

To enter and update data in a CRF, users open the CRF in a Data Entry window. By default, the Data Entry window does not display the Help icon in its toolbar.

RDC adds the Help icon to the toolbar only if you create the context-sensitive help that displays when the user clicks the icon.

To create custom help text for the Help icon, you use the Maintain Links form in the RDC Administration application. For more information, see Section 11.6, "Defining a Link for CRF Help."

13 Configuring Settings for Reports

This chapter includes the following topics:

- Section 13.1, "Defining Settings for the Patient Data Report"

- Section 13.2, "About the File Name for the Deleted CRFs Report"

- Section 13.3, "Customizing Bookmark Labels"

- Section 13.4, "Printing Left Default Prompts for Repeating Response Fields"

13.1 Defining Settings for the Patient Data Report

Using Oracle Clinical, you can configure several settings that control what information is included in a Patient Data Report. You can control:

- Bookmarks in the PDF report file

- Whether to include the approval and verification information for each CRF, the audit history for fields not displayed in the CRF, and the overflow text for hidden protected repeating defaults

- Whether the pages in the table of contents and the cover page are counted when determining the starting page number for the CRFs

The system automatically generates a Table of Contents (TOC) for every report. When you open and view the report, you can click a heading on the Table of Contents pages to go to the selected CRF. The headings, like the bookmarks, are active links to the CRFs.

Figure 13-1 Sample Patient Data Report

13.1.1 Defining the Configuration Settings for the Patient Data Report

In Oracle Clinical, you can define the configuration settings for the Patient Data Report at the database level or at the study level:

- At the database level, the Patient Data Report settings define the default values when a new study is created. For each setting, you can choose to enforce the default value across all studies in the database or allow modification at the study level. You define the default values in the DCI Form Local Database Settings form.

- At the study level, the Patient Data Report settings control the output of the Patient Data Report. You can define all settings at the study level except the PDR Bookmark Data Domain setting.

13.1.1.1 Defining Report Settings at the Database Level

To define the Patient Data Report settings at the database level:

1. Open Oracle Clinical.

2. Navigate to Admin and select DCI Form Local Database Settings.

3. Expand the Patient Data Report node.

4. Change the value of the settings you want. See Table 13-1 for a description of each setting.

5. Select the Enforce Local DB Setting check box to always use this value as the default value.
If not selected, a user who has privileges to the DCI Form Study Database Settings form at the study level can override the default values.

Note that the Enforce Local DB Setting check box is always selected for the PDR Bookmark Data Domain setting because you cannot change its value at the study level.

6. Save your changes.

13.1.1.2 Defining Report Settings at the Study Level

To define the Patient Data Report settings at the study level:

1. Open Oracle Clinical.

2. Navigate to Design and select DCI Form Local Study Settings.

3. Expand the Patient Data Report node.

4. Deselect the Inherit From Local DB Setting check box for any value you want to change.

5. Change the value of the settings you want. See Table 13-1 for a description of each setting.

6. Save your changes.

13.1.2 About the Patient Data Report Settings

Table 13-1 describes the settings that you can use to control the output of the Patient Data Report.

Table 13-1 Settings for the Patient Data Report

Setting

Description

Bookmark Ancillary Data Section

Specifies whether to create bookmarks for the Ancillary Data section associated with a CRF.

- Set to Y to create bookmarks for the sections. When you open and view the report, you can click the bookmark to go directly to the Ancillary Data section for a CRF.

- Set to N to output no bookmarks for the Ancillary Data sections.

Note that the Patient Data Report always includes the Ancillary Data section for a CRF regardless of whether you choose to bookmark the section.

If you choose to bookmark the section, you can specify the title of the bookmark by entering text in the Bookmark Title for Ancillary Data Section setting.

Bookmark Subevents

Specifies whether to create bookmarks for the subevents of a visit.

- Set to Y to creates a bookmark that provides navigation to the first CRF for the subevent.

- Set to N to output no subevent bookmarks. If set to N, the CRFs in the report are still ordered by Visit and Subevent, but the subevents do not appear as separate bookmarks.

Bookmark Title for Ancillary Data Section

Specifies the title to use for the bookmarks to the Ancillary Data sections of the CRFs. To create the bookmark, RDC appends your specified title to the name of any CRF that has an associated Ancillary Data section.

Bookmark Format:  Bookmark-title for CRF-name

Example: Ancillary Data Section for DEMOGRAPHY

This setting is valid only if the Bookmark Ancillary Data Section setting is set to Y. The default value is Ancillary Data Section.

Exclude Overflow for Hidden Protected Repeating Default

Specifies whether the report excludes the overflow text for all repeating default questions that are hidden.

- Set to Y to exclude the overflow text for all repeating questions that are hidden.

- Set to N to include the overflow text in the Ancillary Data section for the CRF.

Note: If the CRF response field for a protected repeating default is less than one character long and this value is set to Y, the Ancillary Data section does not list the values for the response field. By using this combination, you can hide certain fields in a CRF.

Include Approval Information

Specifies whether to include two types of approval information for each CRF: approval history and for approved documents, the approver and date and time of approval.

This setting has effect only if you select the Include Audit History check box when generating the Patient Data Report from the Reports page in RDC or if you specify the -aud parameter when generating the report from the command line.

If set to Y, the Ancillary Data section for each approved CRF includes the following information:

- A statement that the CRF was approved

- The user name of the individual who approved the CRF

- The data and time of the approval

Include Verification Information

Specifies whether to include the verification status and history for each CRF.

- Set to Y if you want the Ancillary Data section of a CRF to include the verification status and history information for each CRF. This audit information is at the end of the Ancillary Data section and is not attached to a superscript on the CRF.

- Set to N to exclude the verification status and history for fields not displayed on the CRF.

This setting has effect only if you select the Include Audit History check box and user has one or more of the Verify privileges (BROWSE_VERIFY, BROWSE_SDVPLAN, UPDATE_SDVPLAN, or VERIFY) when generating the Patient Data Report from the Reports page in RDC Onsite or if you specify the -aud parameter when generating the report from the command line.

Include Audit History for Fields Not Displayed in CRF

Specifies whether to include the audit history for CRF fields that are not displayed in the CRF.

- Set to Y if you want the Ancillary Data section of a CRF to include the audit history information for any field that does not display on the CRF. This audit information is at the end of the Ancillary Data section and is not attached to a superscript on the CRF.

- Set to N to exclude the audit history for fields not displayed on the CRF.

One example of how CRF data is collected but not displayed on the CRF is the Blank Flag icon. In certain circumstances, RDC users may need to mark a CRF as intentionally blank; for example, if a patient fails to appear for a scheduled visit. Users can click the Blank Flag icon to mark a CRF as blank. RDC keeps an audit history of all changes to a CRF.

This setting has effect only if you select the Include Audit History check box when generating the Patient Data Report from the Reports page in RDC or if you specify the -aud parameter when generating the report from the command line.

Include TOC in Page Numbering

Determines how RDC calculates the starting page number for the CRFs listed in the Table of Contents (TOC).

- Set to Y to count the cover page and the TOC pages when calculating the page numbers listed in the TOC. For example, suppose the report has a cover page and a two-page TOC. If set to Y, then the TOC lists the first CRF on page 4 of the report. See Figure 13-1 for an example.

- Set to N to ignore the cover page and the TOC pages. The TOC lists the first CRF on page 1 of the report.

PDR Bookmark Data Domain

Specifies whether to consider the DCI or the DCM as the data domain for the purpose of creating the bookmarks. For the report, the system generates two sets of bookmarks: By Visit and By Domain. See Figure 13-1 for an example of these bookmarks.

- Select DCI if you want to consider each DCI a data domain for the purpose of creating the bookmarks.

- Select DCM if you want to consider each DCM a data domain for the purpose of creating the bookmarks.

You can configure this setting only at the database level. Note that the Enforce Local DB Setting check box is always selected for the PDR Bookmark Data Domain setting because you cannot change its value at the study.

13.2 About the File Name for the Deleted CRFs Report

The name of the PDF output file for the Deleted CRFs Report is constructed based on the Short Values defined in the Oracle Clinical local reference codelist PDR_FILE_NAMING, which you can modify in limited ways:

- You can change the order of the 3 components of the name.

- You can mark any or all components as inactive.

In addition, the string DEL and the job ID are appended at the end of the resulting file name.

The file name format is as follows:

StudyName_StudySiteName_PatientID_DEL_JobID.pdf

Where:

- StudyName can be up to 15 characters.

- StudySiteName can be up to 10 characters.

- PatientID can be up to 10 characters.

- JobID can be up to 10 characters.

For example, pdfrun_ss002_10012_DEL_23546.pdf.

The batch jobs table can accommodate an output file name of up to 70 characters, which includes the reports directory path concatenated to the output file name. If your study name, study site name, and patient ID all use the maximum length allowed by Oracle Clinical, the file name itself will use 52 characters: StudyName(15)_StudySiteName(10)_PatientID(10)_JobID(10).pdf, leaving 18 characters for the directory path. If the 70-character limit is exceeded, the file name will be of the shortened form: oJobID.pdf

Also, if all components in the Oracle Clinical local reference codelist PDR_FILE_NAMING are inactive, the file name will be of the shortened form: oJobID.pdf is used.

Lastly, if the study or study site names include any spaces, those spaces are replaced in the report file name with underscores (_).

13.3 Customizing Bookmark Labels

The RDC Client package contains PL*SQL procedures that you can modify to change the labels for the Domain and Visit bookmarks:

- DCI bookmark label

- DCM bookmark label

- Visit bookmark label

For details on changing these labels, see Chapter 8, "Working with the RDC Client Package."

13.4 Printing Left Default Prompts for Repeating Response Fields

When you setup and define DCM questions in Oracle Clinical, you can define repeating default values for repeating question groups.

To print left repeat default prompts for each repeating response in a CRF:

1. Enter the default response prompt when you define the DCM question in a DCM.

2. Select Left as the prompt position when defining the DCM question group.
Once defined in Oracle Clinical, RDC automatically includes the default repeat prompts for all defined responses to print (and display) in the DCM question group in the CRF:

- When you print a Blank Casebook Report

- When you open a new blank CRF in RDC

14 Generating Reports from the Command Line

In the RDC application, you can use the Reports page to define report parameters, and generate Patient Data Reports and Blank Casebook Reports. In addition, RDC includes a DOS command-line interface for generating either a Patient Data Report or a Blank Casebook Report from the command line.

Generating reports from the command line can be useful when producing electronic submissions for new drug applications (NDAs). Adding the commands to a batch file lets you generate many Patient Data Reports at once.

This chapter includes the following topics:

- Section 14.1, "Configuring Desktop PDR for Report Generation"

- Section 14.2, "Generating a Patient Data Report from the Command Line"

- Section 14.3, "Generating a Blank Casebook Report from the Command Line"

- Section 14.4, "File Names for Reports"

14.1 Configuring Desktop PDR for Report Generation

For every desktop where a user must be able to generate Patient Data Reports or Blank Casebook Reports from the command line, you must:

- Install the Java Runtime Environment (JRE)

- Copy the desktoppdr folder and files to the appropriate location on each desktop

- Copy and Configure the xdobookbinder.cfg File for Embedding Type 1 Fonts

- Copy the xdobookbinder.cfg file to the JRE installation folder, and then modify the file to define the location of the PC's Windows directory

- Edit settings in the RunPDR.cmd file and the RunBlankCasebook.cmd file to configure the user's environment

14.1.1 Contents of the desktoppdr Folder

During the installation of Oracle Clinical, the system creates a desktoppdr folder in the installation directory.

The desktoppdr folder has the following files:

- charsets.jar, olsablankpdr.jar, and olsapdr.jar — Java ARchive (JAR) files containing the required class files for generating Patient Data Reports and Blank Casebook Reports.

- RunBlankCasebook.cmd — Command file used to generate a Blank Casebook Report from the command line.

- RunPDR.cmd — Command file used to generate a Patient Data Report from the command line.

- xdobookbinder.cfg — Configuration file with information about the Arial font generation in the reports.

Figure 14-1 Sample PC Desktop Showing the desktoppdr Folder

14.1.2 Installing the Java Runtime Environment

You must install the Java Runtime Environment (JRE) on the PC desktop if it is not already installed.

The desktop PDR supports Java SE 8 Update 111 (Standard Edition, Version 1.8.0.111) or later.

You can download the JRE from the Oracle Clinical launch page or from the Oracle Web site at this URL:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Check with the system administrator which method to use, if you are not sure.

14.1.3 Copying the Files in the desktoppdr Folder

Copy the desktoppdr folder and its files to the RDC directory on your PC desktop. For example:

C:\opapps52\rdc

In addition, you need to copy the xdobookbinder.cfg file from the desktoppdr folder to the directory where you installed the JRE. For more information, see Section 14.1.5.1, "Copying and Configuring the xdobookbinder.cfg File for Fully Embedding Fonts."

14.1.4 Copying and Modifying the xdo.cfg File

The xdo.cfg file stores system information about the Arial font, which is the font used by the Patient Data Report and the Blank Casebook Report.

During the installation of the Report Server component of Oracle Clinical, the system automatically creates and copies the xdo.cfg file to the following location:

middleware_home/jdk/jre/lib

In addition, any PC that will be used to generate reports from the command line must have a copy of the xdo.cfg file in the JRE installation directory on the desktop. You must also edit the file to define the location of the Windows directory.

To copy and modify the xdo.cfg file:

1. Copy the xdo.cfg file to the following directory where you installed the JRE on your PC desktop:
JRE_Install_Directory/jdk/jre/lib

2. Open the xdo.cfg file with a text editor.

3. Locate the following two lines in the file:
<truetype path="%OUI_WIN_DIR%\fonts\Arial.ttf" />

<truetype path="%OUI_WIN_DIR%\fonts\arialbd.ttf" />

4. Replace each occurrence of the %OUI_WIN_DIR% variable with the location of the Windows directory on your PC.
For example:

<truetype path="C:\WINDOWS\fonts\Arial.ttf" />

14.1.5 Embedding Fonts into the Patient Data Report

By default, when you generate a Patient Data Report, the system:

- Does not embed any Adobe (Type 1) fonts.

- Embeds a subset of the TrueType fonts—only those TrueType font characters that are actually used in the report.

When you use the RunPDR command to generate a Patient Data Report from the command line, you can specify the -cfg parameter to embed the full character set for the fonts used in the report. This may be required for official submissions. Additionally, embedding Acrobat fonts is required if you use Wingbat or Symbol characters. The system uses the information that you specify in the xdobookbinder.cfg file to determine the fonts to embed.

To embed fonts into Patient Data Reports, follow the steps presented in the following section, Copying and Configuring the xdobookbinder.cfg File for Fully Embedding Fonts.

14.1.5.1 Copying and Configuring the xdobookbinder.cfg File for Fully Embedding Fonts

The xdobookbinder.cfg file controls font embedding in the Patient Data Reports. When you install this patch, the system automatically copies the xdobookbinder.cfg file into the desktoppdr folder on the Application Server.

You must copy the xdobookbinder.cfg file to every PC that you will use to generate reports from the command line and embed fonts into the report PDF file. In addition, you must edit the xdobookbinder.cfg file to define the fonts to embed, the location of the Windows font directory, and the location of the Adobe font directory.

To copy and configure the xdobookbinder.cfg file for embedding fonts:

1. Copy the xdobookbinder.cfg file from the desktoppdr folder on the Application Server to the PC. You can copy the xdobookbinder.cfg file to any directory on the PC. You specify the location of the xdobookbinder.cfg file when you execute the RunPDR command.

2. Open the xdobookbinder.cfg file with a text editor.

3. Locate the following lines in the file and verify that the value of the process-font-substitution property is set to true:
<properties><property name="process-font-substitution">true</property></properties>

4. To embed TrueType fonts, replace each occurrence of the %OUI_WIN_DIR% variable with the path to the Windows directory on this PC:
<font-substitute name="Arial"><truetype path="%OUI_WIN_DIR%\fonts\arial.ttf"/></font-substitute>

5. To embed Wingbat or symbol characters, replace each occurrence of the %OUI_ADOBE_FONT_DIR% variable with the path to the Adobe fonts directory on this PC:
<font-substitute name="Symbol"><type1 pfb="%OUI_ADOBE_FONT_DIR%\Sy______.pfb" pfm="%OUI_ADOBE_FONT_DIR%\pfm\Sy______.pfm"/></font-substitute>

Note that the Symbol and ZapfDingbats fonts are Adobe fonts, also called Type 1 fonts. . The fonts must be present on this PC and in the specified directory if you want to embed them into Patient Data Reports.

6. Save your changes.
Here is a sample of xdobookbinder.cfg file:

<config version="1.0.0" xmlns="http://xmlns.oracle.com/oxp/config/">
<fonts>
<!-- Core 14 PDF fonts -->
<font-substitute name="Helvetica">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Helvetica-Oblique">
<truetype path="c:\windows\fonts\ariali.ttf"/>
</font-substitute>
<font-substitute name="Helvetica-Bold">
<truetype path="c:\windows\fonts\arialbd.ttf"/>
</font-substitute>
<font-substitute name="Helvetica-BoldOblique">
<truetype path="c:\windows\fonts\arialbi.ttf"/>
</font-substitute>
<font-substitute name="Times-Roman">
<truetype path="c:\windows\fonts\times.ttf"/>
</font-substitute>
<font-substitute name="Times-Bold">
<truetype path="c:\windows\fonts\timesbd.ttf"/>
</font-substitute>
<font-substitute name="Times-Italic">
<truetype path="c:\windows\fonts\timesi.ttf"/>
</font-substitute>
<font-substitute name="Times-BoldItalic">
<truetype path="c:\windows\fonts\timesbi.ttf"/>
</font-substitute>
<font-substitute name="Courier">
<truetype path="c:\windows\fonts\cour.ttf"/>
</font-substitute>
<font-substitute name="Courier-Bold">
<truetype path="c:\windows\fonts\courbd.ttf"/>
</font-substitute>
<font-substitute name="Courier-Oblique">
<truetype path="c:\windows\fonts\couri.ttf"/>
</font-substitute>
<font-substitute name="Courier-BoldOblique">
<truetype path="c:\windows\fonts\courbi.ttf"/>
</font-substitute>
<font-substitute name="Symbol">
<truetype path="c:\windows\fonts\courbi.ttf"/>
</font-substitute>
<font-substitute name="Symbol">
<type1 pfb="C:\windows\fonts\adobecore14\Sy______.pfb"
pfm="C:\windows\fonts\adobecore14\pfm\Sy______.pfm"/>
</font-substitute>
<font-substitute name="ZapfDingbats">
<type1 pfb="C:\windows\fonts\Zd______.pfb"
pfm="C:\windows\fonts\Zd______.pfm"/>
</font-substitute>
<!-- Arial is not a core PDF font, but sometiimes used -->
<font-substitute name="Arial">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Arial,Italic">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Arial,Bold">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Arial,BoldItalic">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="ArialMT">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Arial-ItalicMT">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Arial-BoldMT">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Arial-BoldItalicMT">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="Univers">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="UniversItalic">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="UniversBold">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<font-substitute name="UniversBoldItalic">
<truetype path="c:\windows\fonts\arial.ttf"/>
</font-substitute>
<!-- TrueType version of TimesNewRoman -->
<font-substitute name="TimesNewRoman">
<truetype path="c:\windows\fonts\times.ttf"/>
</font-substitute>
<font-substitute name="TimesNewRoman,Bold">
<truetype path="c:\windows\fonts\timesbd.ttf"/>
</font-substitute>
<font-substitute name="TimesNewRoman,Italic">
<truetype path="c:\windows\fonts\timesi.ttf"/>
</font-substitute>
<font-substitute name="TimesNewRoman,BoldItalic">
<truetype path="c:\windows\fonts\timesbi.ttf"/>
</font-substitute>
<font-substitute name="TimesNewRomanPSMT">          <truetype path="c:\windows\fonts\times.ttf"/>        </font-substitute>        <font-substitute name="TimesNewRomanPS-BoldMT">          <truetype path="c:\windows\fonts\timesbd.ttf"/>        </font-substitute>        <font-substitute name="TimesNewRomanPS-ItalicMT">          <truetype path="c:\windows\fonts\timesi.ttf"/>        </font-substitute>        <font-substitute name="TimesNewRomanPS-BoldItalicMT">          <truetype path="c:\windows\fonts\timesbi.ttf"/>        </font-substitute>        <!-- Fonts used for W-2 -->        <font-substitute name="FranklinGothic-Demi">          <truetype path="c:\windows\fonts\framd.ttf"/>        </font-substitute>        <font-substitute name="Helvetica-Condensed">          <truetype path="c:\windows\fonts\arialn.ttf"/>        </font-substitute>        <font-substitute name="Helvetica-Condensed-Black">          <truetype path="c:\windows\fonts\arialnb.ttf"/>        </font-substitute>        <font-substitute name="HelveticaNeue-Bold">          <truetype path="c:\windows\fonts\arialbd.ttf"/>        </font-substitute>        <font-substitute name="HelveticaNeue-BoldItalic">          <truetype path="c:\windows\fonts\arialbi.ttf"/>        </font-substitute>        <font-substitute name="HelveticaNeue-Italic">          <truetype path="c:\windows\fonts\ariali.ttf"/>        </font-substitute>        <font-substitute name="HelveticaNeue-Roman">          <truetype path="c:\windows\fonts\arial.ttf"/>        </font-substitute>        <!-- For Canadian T-4A -->        <font-substitute name="ArialNarrow">          <truetype path="c:\windows\fonts\arialn.ttf"/>        </font-substitute>     </fonts>     <properties>         <!-- The below option can be set to true to adjust character layout,  but setting this option to true may affect page layout -->         <property name="replace-character-widths">false</property>         <!-- Set process-font-substitution=true when you want to process font  substitution in PDFBookBinder -->         <property name="process-font-substitution">true</property>     </properties>  </config>

Note:
The font embedding is configurable. Please set the following property to false in xdobookbider.cfg file if you do not want embedding, like this:

<properties>
<property name="process-font-substitution">false</property>
</properties>

When you execute RunPdr command (see 13.2) you must include the -cfg parameter to specify the location of the xdobookbinder.cfg file on your PC. In addition, the fonts must be located on the same machine that you use to run the report.

For example:

RunPDR.cmd -st test3 -l D:\temp -u jsmith -cfg D:\pdr\xdobookbinder.cfg

14.1.6 Modifying the RunPDR.cmd File

To modify the RunPDR.cmd file:

1. Navigate to the desktoppdr folder on your PC.

2. Open the RunPDR.cmd file with a text editor.

3. Modify the following lines in the file:

1. set JAVA_CMD to the directory path where you installed the JRE. For example:
set JAVA_CMD=C:\Progra~1\Java\jre\bin\java

2. set JAR_PATH to the directory path where you installed the JAR files (charsets.jar, olsapdr.jar, and olsablankpdr.jar). For example:
set JAR_PATH=C:\OLSAPDR

3. set DB_CONNECT_STRING in the following format to specify the database connection:
host-name:port-number:database-sid

For example, if you have a database with sid, proddb, that is installed on the prodserver host machine at port number 1532, then you define your database connection string as follow:

set DB_CONNECTION=prodserver:1532:proddb

4. In the command line, add the -Xms and the -Xmx options to set the initial and maximum amount of memory for the report generation. For example:
%JAVA_CMD% -classpath %CLASSPATH% -Xms64M -Xmx512M %JAV…

For more information on these options, see Section 14.1.8, "Adjusting the Heap Size for the Java Virtual Machine (JVM)."

4. Save your changes.

5. Copy and rename the RunPDR.cmd file for every database that your users need to connect to and access. For example, if your users need to connect to a production database and a test database, create the following two new files: RunPDRprod.cmd and RunPDRtest.cmd.

6. Open each copy of the RunPDR.cmd file.

1. Modify the set DB_CONNECT_STRING parameter for each database connection.

2. Save your changes.

14.1.7 Modifying the RunBlankCasebook.cmd File

To modify the RunBlankCasebook.cmd file:

1. Navigate to the desktoppdr folder on your PC.

2. Open the RunBlankCasebook.cmd file with a text editor.

3. Modify the following lines in the file:

1. set JAVA_CMD to the directory path where you installed the JRE. For example:
set JAVA_CMD=C:\Progra~1\Java\jre\bin\java

2. set JAR_PATH to the directory path where you installed the JAR files (charsets.jar, olsapdr.jar, and olsablankpdr.jar). For example:
set JAR_PATH=C:\OLSAPDR

3. Use the following lines to specify the database connection:
set HOST=host-name
set PORT=port-number
set SID=database-sid

4. In the command line, add the -Xms and the -Xmx options to set the initial and maximum amount of memory for the report generation. For example:
%JAVA_CMD% -classpath %CLASSPATH% -Xms64M -Xmx512M %JAV…

For more information on these options, see Section 14.1.8, "Adjusting the Heap Size for the Java Virtual Machine (JVM)."

4. Save your changes.

5. Copy and rename the RunBlankCasebook.cmd file for every database that your users need to connect to and access. For example, if your users need to connect to a production database and a test database, create the following two new files:

- RunBlankCasebookprod.cmd

- RunBlankCasebooktest.cmd

6. Open each copy of the RunBlankCasebook.cmd file.

1. Modify the set HOST, set PORT, and set SID parameters for each database connection.

2. Save your changes.

14.1.8 Adjusting the Heap Size for the Java Virtual Machine (JVM)

Report generation may fail with an OutOfMemoryError message. This failure occurs when the Java program needs more memory than the amount currently allocated. As the number of pages in the Patient Data Reports and the Blank Casebook Reports increases, you may need to increase the JVM heap size accordingly.

To support large reports, use the following JVM options to specify the heap size:

- Use the -Xms option to set the initial amount of memory allocated for the program.

- Use the -Xmx option to set the maximum amount of memory that can be allocated for the program.

As a benchmark, Oracle has successfully generated a 4000-page report with an allocation of 4GB.

14.1.8.1 Adjusting JVM Heap Size Options for the Desktop

To adjust the heap size available for reports generated from the command line, you need to modify the RunPDR.cmd file (for Patient Data Reports) and the RunBlankCasebook.cmd file (for Blank Casebook Reports).

To adjust the heap size in the files:

1. Open the RunPDR.cmd file or the RunBlankCasebook.cmd file.

2. Locate the following line in the file:
%JAVA_CMD% -classpath %CLASSPATH% …

3. Add the -Xms and -Xmx options to the line. For example:
%JAVA_CMD% -classpath %CLASSPATH% -Xms64M -Xmx512M %JAVA…

Substitute the 64M value for the initial amount of memory to allocate, and the 512M value for the maximum amount of memory to allocate.

4. Save your changes.

14.1.8.2 Adjusting JVM Heap Size Options on the Reports Server

You can adjust the heap size available to reports generated from either the RDC or the Oracle Clinical application.

To adjust the heap size on the Reports Server:

1. Log in to Oracle Enterprise Manager 10g Application Server Control.

2. Click the name of the Reports Server (for example, oclw2k36) in the System Components table.

3. Click the Configuration link in the Administration section. The system opens the Configuration page and displays the Reports Engine Parameters section.

4. Click the JVM Option field. Set the appropriate values for the JVM heap size options as follows:
-Xms64M -Xmx512M

Substitute the 64M value for the initial amount of memory to allocate, and the 512M value for the maximum amount of memory to allocate.

5. Click OK to save your changes. The system prompts for confirmation to restart the Reports Server now.

6. Click Yes. You must restart the Reports Server before your changes to the JVM heap size will take effect.
When the system confirms that the Reports Server has been restarted, click OK.

14.2 Generating a Patient Data Report from the Command Line

You can generate a Patient Data Report by issuing the RunPDR command from the Microsoft Windows command line.

You enter the RunPDR command in the following format:

RunPDR.cmd -st study [-si study_site] [-p patient] [-bk DCI_Book]
-l folder_location -u user [-pw password] [-aud] [-disc] [-debug] [-trace] [-nobm] [-o orientation] -cfg xdobookbinder_location [-test]

For example:

RunPDR.cmd -st test3 -l D:\temp -u jsmith -cfg D:\pdr\xdobookbinder.cfg

14.2.1 Displaying the Command Syntax

To display the syntax for the command:

1. Type RunPDR on the command line.

2. Press Enter.

14.2.2 Parameters for the RunPDR Command

Table 14-1 describes the required and optional parameters for the RunPDR command.

Table 14-1 Parameters for the RunPDR Command

Parameter

Required?

Description

-st study

Yes

Runs the Patient Data Report for the specified study. The system produces a separate PDF report file for each patient.

-si study_site

No

Runs a report for all patients currently assigned to the specified study site. If you do not specify a site, the system runs the report for all patients assigned to those study sites that your user role has privileges to access. The system produces a separate PDF report file for each patient.

-p patient

No

Runs a report for the specified patient only. If you do not specify a patient, the system runs a report for all patients in the specified study and sites.

-bk DCI_Book

No

Denotes the DCI Book (casebook) to use for any CRF that was not entered against a casebook. Note that:

- If you do not specify this parameter and a CRF was not entered against a DCI Book, the system uses the casebook assigned to the patient.

- If no casebook is assigned to the patient, the system uses the default casebook for the study.

- If no default casebook exists for the study, the system uses the first active DCI Book, in alphabetical order, for the study.

-l folder_location

Yes

Specifies the directory where the system saves the PDF file created for each report, and the log files created during the generation of the report.

In addition, the system uses this directory to write the debug information if you include the -debug parameter on the command line. The directory that you specify must already exist. If the directory does not exist, the command fails and displays an error message that the folder is invalid.

-u user

Yes

Specifies your user name for logging in to the Oracle Clinical database.

-pw password

No

Specifies your password for logging in to the Oracle Clinical database. When you use this parameter, your password is visible on the screen.

If you do not use this parameter, the system prompts you for your password. Asterisks mask your password as you type it. For security reasons, Oracle recommends that you do not specify your password directly on the command line.

-aud

No

Includes change history for individual responses. In addition, if the DCI Form Settings Include Approval Information and Include Verification Information are set to Y, approval history and verification history will also be included.

Note: The verification history appears only if the user generating the report has one or more of the Verify privileges (BROWSE_VERIFY, BROWSE_SDVPLAN, UPDATE_SDVPLAN, or VERIFY).

-disc

No

Includes discrepancy information in the report.

-debug

No

Leaves data in temporary tables and outputs files to the directory that you specified with the -l folder_location parameter. This data is useful when working with customer support to debug an issue. After you resolve the issue and the debug information is no longer necessary, be sure you truncate the temporary pdr_temp and pdr_superscripts tables.

-trace

No

Turns on database trace and creates a trace file during the execution of the report. Trace data is useful when debugging performance problems. The system saves the trace file in the directory specified in the init.ora file of the database. Check with your database administrator for the location.

-nobm

No

Does not create the bookmarks or a table of contents for the report.

-o orientation

No

Denotes the orientation of the pages in the cover, table of contents, ancillary data sections, and appendixes. Valid entries are:

- P = portrait (default)

- L = landscape

-test

No

Runs the report in test mode for test data. The report uses provisional DCI form versions in place of active ones when the provisional versions exist.

-cfg xdobookbinder_location

No

Location (path, excluding file name) of xdobookbinder configuration file. If executing command line PDR from a client, provide the xdobookbinder configuration file as a parameter to ensure that all fonts are correctly embedded in the PDR and similar output with similar fonts is generated when compared to the report output generated from Oracle Clinical and RDC. If you omit to provide the parameter from the command line, the PDR report output could use different fonts compared to the output generated from the application server.

See "Copying and Configuring the xdobookbinder.cfg File for Fully Embedding Fonts".

rdci

No

Receives the DCI ID for which PDR needs to be generated.

jid

No

Indicates the job ID for which PDR needs to be generated.

rtyp

No

Pass crfh to generate the CRF report and sdr to generate soft-deleted CRFs report.

doc

No

Indicates the document number for which PDR needs to be generated.

dci

No

Indicates DCI for which PDR needs to be generated.

rtyp

No

Pass crfr to generate CRF Report, crfh to generate CRF History, and sdr to generate soft-deleted CRFs report.

14.3 Generating a Blank Casebook Report from the Command Line

You can generate a Blank Casebook Report by issuing the RunBlankCasebook command from the Microsoft Windows command line.

You enter the RunBlankCasebook command in the following format:

RunBlankCasebook.cmd -st study [-p patient] -bk DCI_Book
-l folder_location -u user [-pw password] [-debug] [-trace] [-o orientation]

14.3.1 Displaying the Syntax for the RunBlankCasebook Command

To display the syntax for the command:

1. Type RunBlankCasebook on the command line.

2. Press Enter.

14.3.2 Parameters for the RunBlankCasebook Command

Table 14-2 describes the required and optional parameters for the RunBlankCasebook command.

Table 14-2 Parameters for the RunBlankCasebook Commands

Parameter

Required?

Description

-st study

Yes

Specifies the name of the study to use for the generated report.

- If you do not include the -p patient parameter, the system generates a Blank Casebook Report for the casebook defined in the -bk DCI_Book parameter.

- If you include the -p patient parameter, the system generates a Blank Casebook Report that is specific to a particular patient.

-p patient

No

Specifies a unique patient number (ID). The system generates a Blank Casebook Report that is specific to the specified patient.

-bk DCI_Book

Yes

Specifies the name of the DCI Book (casebook) to use for the generated report.

Note that for a patient-specific report, this value may not match the casebook assigned to the specified patient.

-l folder_location

Yes

Specifies the directory where the system saves the PDF file created for each report, and the log files created during the generation of the report.

In addition, the system uses this directory to write the debug information if you include the -debug parameter on the command line. The directory that you specify must already exist. If the directory you specify does not exist, the command fails and displays an error message that the folder is invalid.

-u user

Yes

Specifies your user name for logging in to the Oracle Clinical database.

-pw password

No

Specifies your password for logging in to the Oracle Clinical database. When you use this parameter, your password is visible on the screen.

If you do not use the -pw parameter, the system prompts you for your password. Asterisks mask your password as you type it. For security reasons, Oracle recommends that you do not specify your password directly on the command line.

-debug

No

Leaves data in temporary tables and outputs files to the directory that you specified with the -l folder_location parameter. This data is useful when working with customer support to debug an issue. After you resolve the issue and the debug information is no longer necessary, be sure you truncate the temporary pdr_temp and pdr_superscripts tables.

-trace

No

Turns on database trace and creates a trace file during the execution of the report. Trace data is useful when debugging performance problems. The system saves the trace file in the directory specified in the init.ora file of the database. Check with your database administrator for the location.

-o orientation

No

Denotes the orientation of the pages in the cover, table of contents, ancillary data sections, and appendixes. Valid entries are:

- P = portrait (default)

- L = landscape

14.4 File Names for Reports

The name of the PDF output file for the Patient Data Report and the Blank Casebook Report uses the format that is specified in the local reference codelist PDR_FILE_NAMING:

STUDY_SITE_PATIENT_JOBID.pdf

where STUDY, SITE, PATIENT, and JOBID are the study name, the study site name, the patient number, and the batch job ID, respectively.

Example: pdfrun_ss002_1001_25366.pdf

Notes:
If you generate a Blank Casebook Report that is not specific to a patient, the PDF file name does not include the site and patient information. In this case, the output file name has the format STUDY_JOBID.pdf.
Also, the file name can have up to 70 characters. If the file name would exceed this limit, the file name has the format oJOBID.pdf.

Lastly, if the study or study site names include any spaces, those spaces are replaced in the report file name with underscores (_).

The file naming rules apply for reports generated from Oracle Clinical, from RDC, or from the command line, except for CRF Reports submitted from the RDC CRF Review page or from the RDC Data Entry window.

About the File Naming Conventions

The file naming conventions follow the PDF specifications defined by the United States Food and drug Administration (FDA).

- Use numeric and lowercase alphabetic characters.

- Use hyphens (-) and underscores (_), as necessary.

- Do not use spaces, punctuation, or other non-alphanumeric symbols (for example, \ / : * ? < > | " % # +).

In addition, these naming conventions comply not only with the FDA guidelines, but also with Image Solutions eCTD Express tool for publishing eSubmissions.

15 Collecting Debug Data

If you encounter problems in RDC, Oracle Support may ask you to collect diagnostic information from the application. There are various diagnostics that can be enabled.

Oracle Support provides instructions on the traces you need to collect depending on the type of error you encounter. This chapter provides instructions on how to collect the various trace files and log files for analysis by Oracle Support.

This chapter includes the following topics:

- Section 15.1, "Displaying Document Numbers in the RDC Application"

- Section 15.2, "Displaying Discrepancy IDs in the RDC Application"

- Section 15.3, "Debugging the Migration Utility"

- Section 15.4, "Debugging the Patient Data Report"

- Section 15.5, "RDC Log Files"

- Section 15.6, "Debugging Performance Issues in the Data Entry Window"

- Section 15.7, "Tracking Scalability Data for RDC"

15.1 Displaying Document Numbers in the RDC Application

Several screens in the RDC application display the name of the CRF (document) in the CRF Name column. Recall that the terms CRF (RDC) and document (Oracle Clinical) are synonyms and used interchangeably.

To assist you with debugging some errors, you can choose to display the document (CRF) number in addition to the document (CRF) name.

To display the document number, specify the &display_docnum=Y parameter in the URL that starts the RDC application. For example:

https://server.domain/rdcadfsrnd/faces/Login?setUpDone=Y&display_docnum=Y

When you set the &display_docnum parameter, the RDC application inserts a CRF Number column to the right of the CRF Name column:

- On the Review CRFs page

- On the Review Discrepancies page

- In the Discrepancy Details window

- On the Review Investigator Comments page

Configuring the &display_docnum parameter is not dependent on enabling the debug feature for other modules.

15.2 Displaying Discrepancy IDs in the RDC Application

To display the discrepancy identifier (ID), add the following parameter to the URL that starts the RDC application:

&display_descpId=Y

For example:

https://server.domain/rdcadfsrnd/faces/Login?setUpDone=Y&display_descpId=Y

When you set the &display_descpId parameter, RDC adds a Discr ID column to the Review Discrepancies page and the Discrepancy Details window. The Discr ID column displays to the right of the CRF Number column.

Configuring the &display_descpId parameter is not dependent on enabling the debug feature for other modules.

15.3 Debugging the Migration Utility

To debug the migration utility, edit a user account to change its last name to DEBUG and then execute the process as that user. This inserts debug messages for the process in the OPA_DEBUG table.

15.4 Debugging the Patient Data Report

To enable the debugging feature for the Patient Data Report:

1. Log in to the Reports Server.

2. Stop the Reports Service.

3. Open the Windows Registry Editor:

1. Click Start and then select Run.

2. Type regedit and then click OK.

4. Navigate to the following location in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\OH_<NUMBER>

5. Create or find the registry key OC_RPT_DEBUG and set its value to Y.

6. Create or find the registry key OC_RPT_DEBUG_TMP_FOLDER. Set its value to the directory where RDC will create and store the temporary files for debugging the Patient Data Report. For better performance, Oracle recommends setting the value to a directory on the Reports Server.

7. Restart the Reports Service.

8. Open RDC and edit the URL to add &debug=all.
With this setting in the URL, RDC keeps the temporary XML files used to generate the PDR and also writes debug messages in the OPA_DEBUG table.

9. Submit the request to generate the Patient Data Report.
When you set OC_RPT_DEBUG = Y, RDC does not delete the records in the following temporary tables when it finishes generating the Patient Data Report:

- PDR_TEMP

- PDR_SUPERSCRIPTS

- PDR_AUDIT_TEMP

In addition, RDC does not delete the PDR temporary files stored in the directory defined by the OC_RPT_DEBUG_TMP_FOLDER registry key.

When you are finished debugging the Patient Data Report, be sure to turn off the report debugging feature so your system does not accumulate temporary tables and files for every Patient Data Report generated.

To disable the report debugging feature, return to the Windows Registry Editor and change the value of the registry key OC_RPT_DEBUG to N.

Note:
The jlog file is located in the user's Reports Server Log directory. RDC creates this file regardless of the value set for the OC_RPT_DEBUG registry key.

15.5 RDC Log Files

RDC has the following log files:

Notes:
By default, middleware_home is C:\app\oracle\middleware.
OpaServer1 is the name of the WebLogic Server instance that is created when installing Oracle Clinical Front End.

Table 15-1 Summary of RDC Log Files

File

Description

Location

Needs Debug Parameter in URL?

WebLogic Server logs

Set in logging.xml; see Section 15.5.2.1, "Editing the logging.xml file for Debugging"

No

RDC application logs

Surround and Data Entry Java log files created by WebLogic Server

Set in logging.xml; see Section 15.5.2.1, "Editing the logging.xml file for Debugging"

Yes; see Section 15.5.2.2, "Editing the URL for Debugging"

RDC DCAPI (data entry) logs

Three per data entry session. See Section 15.5.3.3, "Data Capture API (DCAPI) Logs"

Set in rdcConfig.properties; see Section 3.4, "Required Parameters in an rdcConfig.properties File"

Yes; see Section 15.5.2.2, "Editing the URL for Debugging"

DCAPI framework logs

Launching and managing data entry sessions (DCAPI instances). See Section 15.5.3.4, "Data Capture API (DCAPI) Framework Logs"

Set in rdcConfig.properties; see Section 3.4, "Required Parameters in an rdcConfig.properties File"

Yes; see Section 15.5.2.2, "Editing the URL for Debugging"

OpaServer1.out, OpaServer1.log, and OpaServer1-diagnostic.log

See Section 15.5.1, "Locating the WebLogic Server Log Files"

middleware_home\user_projects\domains\OPADomain\servers\OpaServer1\logs

No

${weblogic}-rdc_1.log (for example, OpaServer1-rdc_1.log

For activity in the application pages, RDC records all logs against a user identifier that consists of the user name, the database, and the HTTP session ID. See Section 15.5.3.1, "RDC Application Pages Log Files"

middleware_home\user_projects\domains\OPADomain\config\fmwconfig\servers\OpaServer1\logs \

No

${weblogic}-de_1.log (for example, OpaServer1-de_1.log)

For activity in the data entry pages, RDC records all logs against a user identifier that consists of the user name, the database, and the HTTP session ID. See Section 15.5.3.2, "RDC Data Entry Window Log Files"

C:\app\oracle\middleware\user_projects\domains\OPADomain\servers\OpaServer1\log

No

access_log

RDC automatically creates these files and continuously collects debug information.

middleware_home\user_projects\domains\OPADomain\servers\host_name_OPA_instance_no\logs\access.log

No

error_log

RDC automatically creates these files and continuously collects debug information.

middleware_home\user_projects\domains\OPADomain\servers\host_name_OPA_instance_no\logs\access.log

No

Also see:

- Section 15.5.4, "Enabling a SQL Trace for Searches"

- Section 15.5.5, "Error when a Failure Occurs during Data Entry"

- Section 15.5.7, "Dump File for a Data Entry Fatal Failure Error"

15.5.1 Locating the WebLogic Server Log Files

The WebLogic server by default records logs for all deployed applications. You use the following log files when debugging errors:

- OpaServer1-diagnostic.log

- OpaServer1.log

- OpaServer1.out

Note:
OpaServer1 is the name of the WebLogic server instance that is created when installing the Oracle Clinical Front End.

RDC stores these log files in the following directory on the application server:

middleware_home\user_projects\domains\OPADomain\servers\host_name_OPA_instance_no\logs

15.5.2 Setting Up Debugging

15.5.2.1 Editing the logging.xml file for Debugging

In order to enable the debug information for the errors that occur when using any RDC application page, the Data Entry window or both, the logging.xml file needs to be updated as follows.

Go to the following location:

middleware_home\user_projects\domains\OPADomain\config\fmwconfig\servers\OpaServer1

Open logging.xml, the logging configuration file and insert the following:

<?xml version='1.0' encoding='UTF-8'?>
<logging_configuration>
<log_handlers>
..
..
<log_handler name='rdchandler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'
filter='oracle.dfw.incident.IncidentDetectionLogFilter'>
<property name='path'
value='${domain.home}/servers/${weblogic.Name}/logs/${weblogic.Name}-rdc_1.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='encoding' value='UTF-8'/>
<property name='useThreadName' value='true'/>
<property name='supplementalAttributes' value='J2EE_MODULE.name,composite_name,component_name'/>
</log_handler>
<log_handler name='dehandler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'
filter='oracle.dfw.incident.IncidentDetectionLogFilter'>
<property name='path'
value='${domain.home}/servers/${weblogic.Name}/logs/${weblogic.Name}-de_1.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='encoding' value='UTF-8'/>
<property name='useThreadName' value='true'/>
<property name='supplementalAttributes' value='J2EE_MODULE.name,composite_name,component_name'/>
</log_handler>
..
..
</log_handlers>
<loggers>
..
..
<logger name='oracle.pharma.rdc.logging' level='ALL'
useParentHandlers='false'>
<handler name='rdchandler'/>
</logger>
<logger name='oracle.pharma.rdc.de' level='ALL'
useParentHandlers='false'>
<handler name='dehandler'/>
</logger>
..
..
</loggers>
</logging_configuration>

For more information on how to configure the WebLogic server logs, see the Oracle Clinical Administrator's Guide.

For more information about Oracle WebLogic Server, see http://docs.oracle.com/middleware/12212/wls/index.html.

15.5.2.2 Editing the URL for Debugging

You can collect debug information for errors that occur when using any of the RDC application pages and when using the Data Entry window.

To collect this debug information, add the &debug parameter to your URL that starts the RDC application:

&debug=module-name

where module-name defines the type of debugging you want.

Valid entries for module-name:

- surround (only debug errors pertaining to the RDC application pages, such as the Home page, Casebooks page, Review CRFs page, PSDV page, etc.)

- de (only debug errors pertaining to the RDC Data Entry window)

- all (debug errors pertaining to both the RDC application pages and the Data Entry window)

General format of the URL:

https://server.domain/rdcadfsrnd/faces/Login?setUpDone=Y&debug=module-name

Examples:

https://pharma.company.com/rdcadfsrnd/faces/Login?setUpDone=Y&debug=de

https://pharma1.usa.atlantic.com/rdcadfsrnd/faces/Login?setUpDone=Y&debug=all

On using application with debug turned on (setUpDone=Y&debug=module), the debug logs would be created in the in the application_path\log defined in the rdcConfig.properties file.

Note:
If a path is not specified for application_path, the default location used is OPA_HOME/log. e.g. C:\opapps52\log

15.5.3 Types of Log Files

15.5.3.1 RDC Application Pages Log Files

Locate and check the ${weblogic.Name}-rdc_1.log log files for the application pages.

RDC records all logs against a user identifier that consists of the user name, the database, and the HTTP session ID.

You can locate all the log entries for the user for a particular RDC session by searching for the HTTP session ID in the log file. The HTTP session ID is the alphanumeric string that follows the user@database information in the <MSG_TEXT> tag.

15.5.3.2 RDC Data Entry Window Log Files

RDC records all logs against a user identifier that consists of the user name, the database, and the HTTP session ID.

To review the information in the data entry logs:

1. Locate and check the ${weblogic.Name}-de_1.log log files for the data entry window. See Section 15.5.2.1, "Editing the logging.xml file for Debugging" for more information.

2. Use the same session ID to locate the data entry logs.
When the user opens a Data Entry window, RDC assigns a unique ID to the window. In addition, RDC creates a log entry against the user's HTTP session ID.

You can locate all data entry logs relevant to the user for the data entry session using the HTTP session ID and the Window context ID. The following example highlights these IDs in bold.

[9e46412a075dc5104ec7e9a06b704bbfb121525115d20e641d6835974ac786e8] Window context Id for this CRF: 4750992751934458

15.5.3.3 Data Capture API (DCAPI) Logs

Every data entry session is supported by a data capture engine running on the middle tier for that session. This engine consists of the following parts:

- A Java layer

- A process (olsadcapiservice.exe)

- A DLL (olsadcapi.dll) loaded by the process

Each part generates a log file when logging is enabled.

DCAPI log files contain internal technical messages that may be meaningful to Oracle support and development only.

The name of these log files use the following format:

- Java layer: DcapiJava_user-name_date-time.dbg

- Process layer: DcapiExec_user-name_date-time.dbg

- DLL layer: DcapiHtml_user-name_date-time.dbg
where:

user-name is the user's login ID.

date-time is the date and time of the event. For example, 2009Aug15134550236.

15.5.3.3.1 Location of DCAPI Log Files

The DCAPI log files are located as defined in the application_path\log defined in the rdcConfig.properties file.

Note:
If a path is not specified for application_path, the default location used is OPA_HOME\log, for example C:/opapps52/log.

15.5.3.3.2 Log Level for DCAPI Log Files

There are no log levels associated with DCAPI logs.

15.5.3.3.3 Enabling DCAPI Logging

DCAPI logging is automatically enabled whenever you enable logging for data entry. To enable logging for data entry, add the &setUpDone=Y&debug=ALL parameters to the URL that starts the RDC application.

15.5.3.3.4 Locating DCAPI Log Entries

The way to link DCAPI logs to your data entry session is by noting the user name and the approximate time when the data entry session started and then locating the corresponding log files.

15.5.3.4 Data Capture API (DCAPI) Framework Logs

You can enable RDC to generate DCAPI framework logs that capture logs from the common code that creates, manages, and closes DCAPI instances. The DCAPI generates two log files for each instance running WebLogic Admin Server. These log files help when troubleshooting issues with launching data entry sessions.

To enable DCAPI framework logging:

1. Login to admin server console for OPADomain and locate olsardc. See Section D.1, "Locating the olsardc.ear File" for details.

2. Open olsardc.ear using any utility to unzip. See Section D.2, "Manually Extracting and Repacking the olsardc.ear File" for details.

3. Navigate to the following path: middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear\RdcS urroundAdfWebUIWebApp.war\WEB-INF\

4. Locate and open dcapi.properties with a text editor.

5. Find the following parameter and set the value to 1:
frameworklog=1

6. Find the following parameter:
frameworkloglocation=

Specify the location for the DCAPI framework log files. For example, if you want the DCAPI to save the framework log files in the RDC log folder, set the parameter as follows:

frameworkloglocation=drive:\\RDC_HOME\\log

Note that you must specify the double forward slash throughout the directory path. Otherwise, the Java APIs read the single slash as an escape character.

7. Save your changes.

8. Re-deploy olsardc. See Section D.4, "Redeploying RDC with Customizations" for details.

9. Restart the OpaServer. See Section D.5, "Restarting the OPA Server" for details.

Once you log in to RDC and open a CRF, the DCAPI generates the framework log files and continuously adds logs to the files. The names for the framework log files use the following format:

- OHSA_DCAPI_Framework_Java_n.log

- OHSA_DCAPI_Framework_Native_n.log
where n is the JVM instance number. (If a single JVM is running the OC4J instance, then n is 1.)

15.5.4 Enabling a SQL Trace for Searches

To enable a SQL trace for searches (queries) executed during a user session, add the &sqlTrace=true parameter to the URL that starts the RDC application.

For example:

https://server.domain/rdcadfsrnd/faces/Login?setUpDone=Y&sqlTrace=true

Note:
If you need a SQL trace for the Data Entry window, you must enable the trace at the user level by a login trigger. Contact Oracle Support for instructions and assistance with this type of trace.

The trace file is generated on the database server.

1. Log in to the database server.

2. Connect to SQL*Plus as system:
sqlplus system

3. Execute the below query to locate the trace file:
select value from v$diag_info where name='Diag Trace';

15.5.5 Error when a Failure Occurs during Data Entry

When an error occurs while working in the Data Entry window, RDC displays an error message in the following format:

Table 15-2 describes the types of errors that can occur and the corresponding error_text that displays with the message.

Table 15-2 Errors and the Text Added to the Message

Type of Error

Text Added to the Message

Network drop, error from Internet Explorer, or error from the Application Server

XMLHttp error code error_number, (additional_error_text)

Note that under most circumstances, RDC handles a momentary network drop, and displays a different message that presents a Retry option to the user. However, in some cases, a network drop results in the Data Entry window shutting down.

Error in the data entry code

Log code error_number, internal error.

Error in the DCAPI

Log code error_number, data capture error.

15.5.6 Locating Log Files for a Fatal Failure during Data Entry

In the case of a fatal failure, RDC displays the error message and log code information. See Figure 15-1.

Figure 15-1 Fatal Error Dialog Box with Log Code information

When the error occurs, the RDC user should record the log code number and the error text, and then report the information to you. For example:

Log code 9522631529, data capture error.

You can use the log code to search the log file and get more details on the error. Two important notes:

- The exact code can be in any one of the log files in the OpaServer1 log location folder.

- The particular log file that contains the log code may be deleted if you do not read the log within a reasonable time after the failure because the log size limits can force the logger to delete log files and create new files to accommodate new logs.

Note:
In case of critical errors or failures in the Data Entry window, RDC automatically generates a log entry even if you did not enable logging from the URL. RDC users should always record the log code when the error occurs. Subsequently, you can use the log code to reference additional information about the error.

15.5.7 Dump File for a Data Entry Fatal Failure Error

A fatal failure in a data entry session always generates a dump file on the middle tier that contains information relevant to the failure. This information will help Oracle support and developers troubleshoot issues.

15.5.7.1 Location of the Dump File

The name of the dump file uses the following format:

logcode.dump

where logcode is the log code that appears in the Data Entry window in case of a fatal failure.

RDC creates this file on the middle tier inthe application_path\log directory defined in the rdcConfig.properties file.

15.5.7.2 Enabling Dump File Creation

RDC always creates dump files in the case of a fatal failure in data entry, with or without logging enabled. However, it is helpful to Oracle support if you generate and gather more information by enabling logging for data entry.

For critical errors, Oracle suggests that you set the data entry log level to FINEST, and then reproduce the failure to generate the maximum amount of log information.

Choosing Data Entry Log Level

You can set the level of detail for the Data Entry logs with the value of the parameter level, found in the dataentrylogger.properties file. Any of the following is valid:

- FINE

- FINER

- FINEST

- WARNING

- SEVERE

To modify the value, perform the following steps:

1. Login to admin server console for OPADomain and locate olsardc. See Section D.1, "Locating the olsardc.ear File" for details.

2. Open olsardc.ear using any utility to unzip. See Section D.2, "Manually Extracting and Repacking the olsardc.ear File" for details.

3. Navigate to the following path: middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear\RdcS urroundAdfWebUIWebApp.war\WEB-INF\

4. Open the dataentrylogger.properties file with a text editor, find the parameter level and set the value to FINEST:

level=FINEST

5. Save your changes.

6. Re-deploy RDC. See Section D.3, "Deleting the Existing Deployment" for details.

7. Restart the opaserver. See Section D.4, "Redeploying RDC with Customizations" for details.

15.5.7.3 Reading a Dump File

When a fatal failure occurs in a data entry session, the RDC user should note the log code and report it to you. You can use the log code to locate the dump file in the application_path\log directory.

The dump files has several key sections to help with troubleshooting.

As shown in Example 15-1, the first long alphanumeric string in the first section provides the following important identifiers:

- The HTTP session ID for the user

- The user name and database

- The Window Context session ID for the Data Entry window where the failure happened

- The time stamp for the DCAPI log

Example 15-1 Important Identifiers in the Dump File

#Starting dump of context parameters for failureId: 9522631529
#---------------------------------------------------------------
refids=0a957842231c103dc782a58e44a49c2089684b16a007,
<user>@<database>,28905006072188144,2009Jul15161040954

You use the user's session ID, the user name, the database, and the window session ID to search the ${weblogic.Name}-de_1.log (as configured in logging.xml) for all relevant entries. You use the time stamp to locate the DCAPI log files. See Section 15.5.3.3, "Data Capture API (DCAPI) Logs" for more information.

The next section of the log file lists the actual exception stack.

#---------------------------------------------------------------
Exception Details:Error in DCAPI Module.
oracle.pharma.rdc.de.exception.FailedOperationException: Error in DCAPI Module.
at
oracle.pharma.rdc.de.exception.FailedOperationException.<init>
(FailedOperationException.java:75)
at
oracle.pharma.rdc.de.service.dcs.DciFormData.doFieldUpdate(DciFormData.java:6274)
.
.
.

jvmid=1

15.6 Debugging Performance Issues in the Data Entry Window

Performance profiling can provide Oracle Support with diagnostic information for all the activities that are conducted in the Data Entry window for a particular user session.

In addition to the log files for the application pages and for data entry, RDC lets you monitor performance in different parts of the code. RDC supports performance profiling for the data entry client and for the data entry server code.

15.6.1 Performance Profiling for the Data Entry Client

You can monitor the performance of specific requests from the data entry client user interface to get an overall idea of the time spent in different parts of the code.

To profile a single user session:

1. Start an RDC session using the following URL:
https://server.domain/rdcadfsrnd/faces/Login?setUpDone=Y&deparams=
profile:1

2. Open a CRF where you are seeing the problem of interest. Note that because profiling is turned on, RDC adds the View Profile link to the session information line above the tool bar:

3. Execute the problematic scenario.

4. Click the View Profile link. RDC displays the client profile logs in a separate window. Note that the log shows the times spent on the client in different parts of the JavaScript code including network round-trip times.

5. Copy and paste information from the View Profile window into a text file that you can forward to Oracle Support. (This information is related only to actions around opening the CRF.)

6. Collect the log information and forward to Oracle Support. This includes:

1. Content of the View Profile windows that you copied into a text file.

2. Content of the application_path\log\requestprofilelog.xml file located on the application server.

On the server side, RDC also creates a new log entry for the same request in the requestprofilelog.xml in the folder as configured in the application_path folder as configured in rdcConfig.properties file. This log entry breaks down the time spent on the server side for the same request in different parts of the code. For example:

<request id="1">
<user>user@database</user>
<windowcontext>50645505678382780</windowcontext>
<profiles>
<profile name="generateRDciData">484</profile>
<profile name="loadDciForm">156</profile>
<profile name="cmdDocData">656</profile>
<profile name="cmdPostInitialLoad">94</profile>
<profile name="cmdGetSettings">94</profile>
<profile name="cmdOpenConfirm">0</profile>
<profile name="RuntimeController">922</profile>
</profiles>
</request>

A combination of the client profile data and server profile data gives a complete picture of a request-response life cycle that originated from the data entry client code.

15.6.2 Performance Profiling for Data Entry Server Code

Another kind of profiling supported by the data entry code gives the average, minimum, and maximum times spent in specific portions of the server code over time and across multiple data entry users. All time values are in milliseconds.

To enable server profiling:

1. Navigate to OPA_CONFIG_FOLDER. The folder path is determined by the registry entry opa52, found under HKEY_LOCAL_MACHINE > Software > Oracle.

2. Open the rdcConfig.properties file.

3. Set the performanceprofile parameter value to 1.

4. Save your changes.

5. Restart the OpaServer. See Section D.5, "Restarting the OPA Server" for details.

6. Start the RDC application, and the open a CRF in the Data Entry window.
Because you enabled server profiling, RDC adds the Server Profile link to the session information line above the toolbar in the Data Entry window:

When you click the Server Profile link, RDC opens a separate window with data about the server profile.

The server profile data includes the Profile Name, the number of calls, and the minimum, maximum, and average time. All time values are in milliseconds. For example:

15.7 Tracking Scalability Data for RDC

RDC provides the capability to track the change in certain data related to the scalability of the system. When you enable this feature, RDC tracks the following metrics:

- Number of RDC users

- Number of Business Components for Java (BC4J) application modules

- Number of data entry sessions

- Number of DCAPI instances

15.7.1 Enabling Tracking of Scalability

To enable tracking of scalability:

1. Login to admin server console for OPADomain and locate olsardc. See Section D.1, "Locating the olsardc.ear File" for details.

2. Open olsardc.ear using any utility to unzip. See Section D.2, "Manually Extracting and Repacking the olsardc.ear File" for details.

3. Navigate to the following path: middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear\RdcS urroundAdfWebUIWebApp.war\WEB-INF\

4. Open the web.xml file with a text editor.

5. Insert the following lines into the file:
<context-param>
<param-name>enablesensor</param-name>
<param-value>1</param-value>
</context-param>

Make sure the XML syntax is preserved when you insert these lines.

6. Save your changes.

7. Re-deploy olsardc. See Section D.4, "Redeploying RDC with Customizations" for details.

8. Restart the OPA server. See Section D.5, "Restarting the OPA Server" for details.

15.7.2 Viewing the Scalability Metrics

Once you enable tracking of scalability data, RDC will generate sensor reports at specific intervals. The sensor reports are CSV files. RDC saves the files in the application_path\log folder defined in rdcConfig.properties file.

For each instance running, RDC creates a new folder in the application_path\log folder:

opasensorreport_n

where n is the instance number.

The opasensorreport_n folder has four files that correspond to the metrics collected:

- NumberOfRdcUsers.csv — number of RDC users

- RdcAM.csv — number of BC4J application modules

- NumberOfDEWindows.csv — number of data entry sessions

- NumberOfDcapi.csv — number of DCAPI instances

Each file records a new entry whenever an event that triggers a change in value occurs, for example, when a user logs in or logs out. Note that RDC updates the files only at specific intervals (every 10 minutes). Therefore, the files may not always reflect the latest data.

In each file, the first column is the number of milliseconds since the WebLogic Server was started. The second column represents the number (metric) that is being tracked.

A Setting Up Database Connections

This chapter includes the following topics:

- Section A.1, "Adding WebLogic Server Data Sources"

- Section A.2, "Add Service Name to tnsnames.ora"

- Section A.3, "Configure Maximum Connections"

A.1 Adding WebLogic Server Data Sources

When you run the Oracle Clinical Installer, it sets up a data source for OPA and RDC from the WebLogic Server to a the default database.

If you plan to use more than one database, you must create a data source for RDC for each additional database. If you also are using TMS, you need to create data sources for OPA and the TMS Browser. The OPA connection is used for running TMS reports.

Go through these instructions for one data source at a time.

1. Log in to the WebLogic Server Administration Console at:

http://host:7101/console/login/LoginForm.jsp

2. Select Data Sources, then New, the Generic Data Source.

3. Enter a name for the data source.

4. Enter the JNDI name as:

- For OPA: jdbc/opadatabase_nameDS

- For RDC: jdbc/rdcdatabase_nameDS

- For TMS: jdbc/tmsdatabase_nameDS

5. On the next screen:

- If the database you want to connect to is a RAC database, choose Oracle's Driver (Thin) for Service connections; Versions:9.0.1 and later

- If the database is not a RAC database, choose Oracle's Driver (Thin) for Instance connections; Versions 9.0.1 and later

6. On the next screen, uncheck Supports Global Transactions.

7. On the next screen, enter the database name, host name, and port for the database. For the user, enter the following user account and its password:

- For OPA: bc4j_internal

- For RDC: rdc_midtier_proxy

- For TMS Browser: ops$tms_browser

8. On the next screen, select Test Configuration to validate if you can connect using the pool setup.

9. On the next screen, assign OpaServer1 as the target.

10. Click Finish.

11. Select the newly created Data Source, click the Connection Pool tab, and then click Advanced.

12. Add the property databaseName=OracleDataSource into Properties field.

13. Add the property dataSourceName= sid/database_name into Properties field where sid/database_name accordingly if the property not getting created already by the weblogic admin console's create data source wizard.

14. Uncheck Wrap Data Types and save.

15. Review and set additional parameters in Advanced Settings as appropriate for your expected data load.

16. Activate your changes or restart the OPA server for the changes to take effect. Also see Section D.5, "Restarting the OPA Server".

A.2 Add Service Name to tnsnames.ora

You must also add the service name used to create connection pool to tnsnames.ora on the application server.

The tnsnames.ora file is located in the application instance; for example: middleware_home\application_server_instance\config.

Note:
Oracle recommends maintaining a master tnsnames.ora file and copying it to each location—database and application servers— whenever you add a database.

A.3 Configure Maximum Connections

By default, the maximum number of database connections defined for the Application Module is 75.

You can use the following formula to determine what to set the value to. It:

- Allows 4 connections per concurrent user to support each user having 3 data entry windows.

- Provides an additional buffer because when a user opens data entry the system requires about 5 connections. It then releases 4 of them.

The formula is:

p + n * 3.5

where p is the Application Module pool size and n is the number or concurrent users you expect.

For example, if you expect 10 concurrent user connections and the Application Module pool size is 75, then the formula is 75 + 10 * 3.5, which means that your application can support up to 110 concurrent connections.

The value for the Maximum Capacity parameter for the data source should be equal to or greater than the number of concurrent users you expect for:

- TMS Browser (TMS data source)

- TMS Reports (OPA data source)

To change this value:

1. Log in to the WebLogic Server Administration Console at:

http://host:7101/console

2. Select Data Sources, then select the data source whose setting you want to modify: for example, DS_1_rdc for RDC, DS_1_tms for TMS or DS_1_ops for OPA (TMS reports).

3. Click the Connection Pool tab.

4. Scroll down to find the parameter Maximum Capacity.

5. Enter a value and save.

6. Restart the OPA server to apply your changes.
See Section D.5, "Restarting the OPA Server" for instructions.

Note:
When you create a new data source, create it for a particular application, such as RDC, or TMS, and ensure that it will only be used for that application.

B Generating HTML DE and PDR Templates for Existing DCI Form Versions

To use HTML Data Entry and the graphic Patient Data Report (PDR), you must design graphic layouts for the CRFs. For information on creating layouts and enabling studies for data entry using DCI Forms, see Oracle Clinical Creating a Study.

If you have existing DCI Form Versions where the PDF form was generated, run the upgrade utility to generate BI Publisher Report Templates and HTML Data entry forms for the existing form versions.

You do not have to change your existing layouts. The Report templates and HTML DE forms look the same.

This appendix includes the following topics:

- Creating User Roles that Can Upgrade DCI Forms Only

- Upgrading Existing DCI Form Versions for HTML DE and New PDRs

- Running the Upgrade Utility in Incremental Mode

Note:
To enable image viewing on CRFs during data entry in RDC, you can choose either to set up a central repository or to copy images to all RDC installations. For information on enabling image viewing, see the Oracle Clinical Administrator's Guide.

B.1 Creating User Roles that Can Upgrade DCI Forms Only

By default, users with the role RXC_ADMIN, RXC_SUPER, or RXC_SUPER_NOGL can upgrade the DCI forms that RDC uses for HTML data entry and for the Patient Data Reports.

Note that the process you use to create the user roles that have access to the DCI Forms Upgrade utility is different from the process for creating the user roles for other administrative privileges. Therefore, you can identify user roles for upgrading DCI forms that are different from the roles for performing other administrative tasks.

To modify the set of roles that have privileges to upgrade DCI forms:

1. Log in to the Oracle Clinical database server.

2. Navigate to the Oracle Clinical INSTALL directory.

3. Open the opapb_level_privs_m1.sql file with a text editor.

4. Find the dcif_upgrade_user function.

- Add the roles that you want to have privileges to upgrade DCI Forms.

- Delete any roles you do not want to have the ability to upgrade DCI Forms.

5. Connect to SQL*Plus.

6. Run the SQL script to process your changes:
START opapb_level_privs_m1.sql

Note:
Oracle supports this modification, but you are responsible for re-applying any modification if a patch overrides the package.

B.2 Upgrading Existing DCI Form Versions for HTML DE and New PDRs

To generate HTML forms and PDR templates from existing DCI Form layouts:

1. Open your Web browser.

2. Enter the URL for the upgrade utility.

3. Log in to the upgrade utility using your Oracle Clinical user ID and password.
The Generate PDR Templates and HTML DE Forms form lists all the DCI Form Definition Enabled studies that your user ID can access.

4. Select a study by clicking a row. Make sure the entire row is highlighted in blue to indicate that the study has been selected. Although you can select multiple studies, Oracle recommends that you generate forms for only one study at a time.

5. Click Generate.
A job is initiated to generate an HTML Data Entry form and a BI Publisher report template for every DCI layout in the study for which a DCI Form Version has been generated previously. Note that this job does not run in the background and will take some time.

The Generation Status field in the lower left of the form shows each DCI form version as it is being processed. On the same form, when the job completes, you can select View Log to see whether the application encountered any errors during the execution of the job.

B.3 Running the Upgrade Utility in Incremental Mode

By default, the Upgrade utility will always generate the HTML data entry forms and the PDR templates for all DCI Form Versions in the study that have PDF data entry forms generated.

There may be times when you have problems with the form or template generation. For example, perhaps some images used in the form layout are no longer in the correct location so the Upgrade utility does not generate a few of the DCI Form versions. For such cases, you can temporarily change the utility to run in incremental mode. In incremental mode, the Upgrade utility only creates the HTML data entry forms and the PDR templates if they do not already exist.

After upgrading to Release 5.2 or later, you must run the Upgrade utility for all DCIs in all studies to add hyperlinks in generated PDRs. Otherwise, if you do not run the Upgrade utility for some DCIs, the fields in the documents entered for those DCIs would be rendered blank in the generated PDR. Also, you must regenerate the Form Versions. Otherwise, you would not be able to open Data Entry Window using Microsoft Edge Browser.

To configure the Upgrade utility to run in incremental mode:

1. Open Oracle Clinical.

2. Navigate to Admin, Reference Codelists, and then select Local Codelists.

3. Query for the OCL_STATE reference codelist.

1. Enter OCL_STATE in the Name field.

2. Press F8 to execute the query.

4. Scroll down to the UPD_FV_INCREM short value.

5. Set the long value to Y. Note that:

- Y — Forces the Upgrade utility to run in incremental mode. In incremental mode, the utility will not regenerate HTML data entry forms and PDR templates for form versions that already exist.

- N (default) — Forces the Upgrade utility to generate all form versions.

This setting applies only to running the Upgrade utility for existing DCI Form versions.

Note:
Running the Upgrade utility in incremental mode is for resolving problems. Oracle recommends that you do not continue to run the utility in incremental mode. Be sure to change the UPD_FV_INCREM value back to N after you generate the forms you need.

C Troubleshooting

This chapter describes errors you may receive and information about how to fix them.

This chapter includes the following topics:

- Section C.1, "CLOB Conversion Error Opening Data Entry Window"

- Section C.2, "Executable Creation Error Opening Data Entry Window"

- Section C.3, "Data Entry Window Doesn't Open"

- Section C.4, "RWServlet URL Connection Error"

- Section C.5, "Dcapi error saying dll already loaded"

- Section C.6, "Closing discrepancy of batch loaded CRF error"

- Section C.7, "Application Hangs When User Tries to Open a New Window"

- Section C.8, "Cannot Log In to Application"

- Section C.9, "Oracle Clinical or RDC Not Launching"

- Section C.10, "Cannot Stop Submitted Report Jobs from RDC Onsite"

C.1 CLOB Conversion Error Opening Data Entry Window

If you receive an error when opening a data entry window that includes text about CLOB conversion, you may need to change the Wrap Data Types setting in the connection pool for the data source of the database.

During RDC installation, the Oracle Universal Installer creates one connection pool. If you set up additional connection pools manually, you must uncheck the Wrap Data Types setting for each one.

C.2 Executable Creation Error Opening Data Entry Window

If you open a Data Entry Window and get the error, oracle.pharma.oc.dcapi.DataCaptureEngineException: Failed all attempts to create executable, the problem is probably that the path variable on the application server is too long. This is because every software product installed on the computer adds one or more entries to this variable. Most of these entries are not required.

To fix the problem, clean up the path variable, getting rid of all unneeded entries to bring the total length down to 100 characters or the minimum possible.

1. On your Windows application server, go to the Control Panel, then System and Security, then System, then Advanced System Settings, then the Advanced tab, then Environment Variables.

2. In the System Variables pane, scroll down to the Path variable and select it.

3. Click Edit. In the Variable Value field, edit the value by removing all unneeded values until the total length is less than 100 characters, if possible. Also remove any spaces in the path.

4. Click OK to close each window.

C.3 Data Entry Window Doesn't Open

If you cannot open a Data Entry Window and find the error ORA-12154: TNS:could not resolve the connect identifier specified in the opaServer.out file in a location like: middleware_home\user_projects\domains\OPADomain\servers\Server_Name\logs\Server_Name.out, it is probably because you have not added the database where the CRF is stored to the tnsnames.ora file on the application server.

C.4 RWServlet URL Connection Error

If you are trying to connect to the Application Server using the rwservlet URL and see this error, "rep-52262 diagnostic output is disabled," Reports Server submissions fail.

To fix this:

1. Log on to the Application Server.

2. Go to DomainHome\config\fmwconfig\servers\WLS_REPORTS\applications\reports_12.2.1\configuration.

3. Open rwservlet.properties in a text editor and add the following line below the <inprocess> parameter:
<webcommandaccess>L2</webcommandaccess>

4. Go to ORACLE_HOME\reports\conf.

5. Open rwservlet.properties in a text editor and add the following line below the <inprocess> parameter:
<webcommandaccess>L2</webcommandaccess>

C.5 Dcapi error saying dll already loaded

If you try to open the Data Entry window, after you deleted, and then redeployed the RDC, you see the Dcapi error saying dll already loaded.

When you redeploy the .ear file, for example, after applying a patch, you must restart the WebLogicServer or the Data Entry Window does not open.

To fix this, you need to restart WebLogicServer.

Note:
In general, you don't need to delete and redeploy RDC. However, if you have to do that for any reason, follow the instructions as provided in Appendix D.

C.6 Closing discrepancy of batch loaded CRF error

If you get the following message upon saving a change to a discrepancy or blanking outone or more sections of the CRF: All responses in one or more sections have been deleted. If this is the desired action, please delete the entire document, or contact your help desk to change the status of the document, the problem is that the Save logic detected that the CRF was either batch loaded or in status Pass 2 Started, Complete, or Pending and all responses have been deleted in one or more sections. This is not allowed for CRFs that are either batch loaded or in status Pass 2 Started, Complete, or Pending.

Click OK in response to the message. The system displays the document with your changes to the discrepancy status or blanked fields. You can either delete the CRF or close it, using the option to discard changes -- and then contact your help desk to change the status of the document.

To fix this:

- For new documents that have status PASS 2 and need to have their Blank flag set to Y, you need to do the following:

1. Update the blank flag via RDCI key changes in Oracle Clinical.

2. Migrate the documents so they can be opened again in RDC.

- For documents that already have the problem, you need to do the following:

1. Create a RDCI Key change in Oracle Clinical to change the Blank flag from N to Y for the documents affected.

2. Create a second RDCI Key change to change the Blank flag from N to Y N for the documents affected (the same ones updated in the first key change).

3. Migrate the documents changed. After that it will be possible to open the blank documents in RDC.

C.7 Application Hangs When User Tries to Open a New Window

If a user connecting to RDC using Internet Explorer tries to open a new window and nothing happens, the user may need to increase the number of connections allowed in IE. For instructions from Microsoft, see http://support.microsoft.com/kb/282402#fixit4me. The problem description is about being unable to download only two files at a time, but the fixes described work for the RDC problem.

C.8 Cannot Log In to Application

If a user cannot log in to RDC, he or she may have entered the application's URL twice in the same browser window.

Close all browser windows and try the URL again.

C.9 Oracle Clinical or RDC Not Launching

If Oracle Clinical or RDC do not launch and you get the error

Failure of server APACHE bridge:
No backend server available for connection: timed out after 10 seconds or idempotent set to OFF or method not idempotent

do the following:

1. Log in to the application server.

2. Go to opa_home\log and check if the following files exist:

- autostartopadomain2.log

- autostartopadomain2.err

- autostartfrdomain2.log

- autostartfrdomain2.err

If any of these log files exist, review them for error messages and contact Oracle Support for assistance with any errors.

If you find no errors and the log file ends in Server server_name started, then delete the files and restart the server.

If there are no log files, check that autostart is configured properly. For information on configuring autostart, see Creating Scripts to Automatically Start the Admin and Managed Servers for RDC Onsite and TMS, available on My Oracle Support (Article ID 1628413.1).

C.10 Cannot Stop Submitted Report Jobs from RDC Onsite

If you are unable to stop the submitted report jobs from RDC Onsite:

1. Log on to the Application Server.

2. Go to DomainHome\config\fmwconfig\servers\WLS_REPORTS\applications\reports_12.2.1\configuration

3. Open rwservlet.properties in a text editor and add the following line below the <inprocess> parameter:
<webcommandaccess>L2</webcommandaccess>

4. Go to ORACLE_HOME\reports\conf.

5. Open rwservlet.properties in a text editor and add the following line below the <inprocess> parameter:
<webcommandaccess>L2</webcommandaccess>

D Deploying Customizations

This chapter describes how you can deploy customizations you perform on any file.

After you customize a file, you may need to redeploy the EAR file for your changes to become available. Do so by following the steps below:

- Section D.1, "Locating the olsardc.ear File"

- Section D.2, "Manually Extracting and Repacking the olsardc.ear File"

- Section D.3, "Deleting the Existing Deployment"

- Section D.4, "Redeploying RDC with Customizations"

- Section D.5, "Restarting the OPA Server"

Note:
These processes cause downtime of the application.

D.1 Locating the olsardc.ear File

1. Log in to the administrator server console for OPADomain using a URL of the form http://machinename:port/console.
For example, http://pharma.company.com:7101/console.

2. Click on Deployments and select the checkbox for olsardc.

3. Make a copy of olsardc.ear from the upload folder or equivalent path: middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear.

Note:
To find the upload path, go to the administrator server console for the OPA domain. Click on Deployments, then select the checkbox for olsardc and click Update. The Source path will display the current upload location.

D.2 Manually Extracting and Repacking the olsardc.ear File

If you do not have an unzip utility installed, you can manually extract and then repack the EAR file by following the steps below.

To extract the olsardc.ear file:

1. Open a DOS Command window and navigate to the upload directory.
See Section D.1, "Locating the olsardc.ear File" for information on how to find the upload directory.

2. Back up the olsardc.ear file.

3. Create a new temporary directory called mycustomloc and then copy the olsardc.ear file to that directory as shown in the below example:

C:\mycustomloc>copy C:\app\oracle\middleware\user_projects\domains\OPADomain\servers\AdminServer\upload\olsardc.ear

4. Extract olsardc.ear using the jar utility command:

middleware_home\Oracle_FRHome1\jdk\bin\jar -xvf olsardc.ear

For example:

C:\mycustomloc>C:\app\oracle\middleware\Oracle_FRHome1\jdk\bin\jar -xvf olsardc.ear

The file RdcSurroundAdfWebUIWebApp.war is in the extracted directory.

5. Create another temporary directory called RdcSurroundAdfWebUIWebApp and move the RdcSurroundAdfWebUIWebApp.war to this new directory.

6. Extract the RdcSurroundAdfWebUIWebApp.war file using the jar utility command

middleware_home\Oracle_FRHome1\jdk\bin\jar -xvf RdcSurroundAdfWebUIWebApp.war

For example: C:\mycustomloc\RdcSurroundAdfWebUIWebApp>C:\app\oracle\middleware\Oracle_FRHome1\jdk\bin\jar -xvf RdcSurroundAdfWebUIWebApp.war

After extracting the file, you can access the RDC application WEB-INF directory and all files under it from within the newly extracted directory.

7. Make changes to the files as necessary.

8. Save your changes.

To repack the olsardc.ear file:

1. Open a DOS Command window and navigate to the temporary directory RdcSurroundAdfWebUIWebApp.

2. If present, remove the RdcSurroundAdfWebUIWebApp.war file from this directory.

3. Rebuild the RdcSurroundAdfWebUIWebApp.war file using the jar command

middleware_home\Oracle_FRHome1\jdk\bin\jar -cvf RdcSurroundAdfWebUIWebApp.war *

For example: C:\mycustomloc\RdcSurroundAdfWebUIWebApp>C:\app\oracle\middleware\Oracle_FRHome1\jdk\bin\jar -cvf RdcSurroundAdfWebUIWebApp.war *

The process created the RdcSurroundAdfWebUIWebApp.war file.

4. Move RdcSurroundAdfWebUIWebApp.war to the temporary directory mycustomloc.

5. Navigate to the temporary directory mycustomloc.

6. Delete the RdcSurroundAdfWebUIWebApp directory using the command:

rd /S /Q RdcSurroundAdfWebUIWebApp

7. If present, remove the olsardc.ear file from the mycustomloc directory.

8. Rebuild the olsardc.ear using the jar command:

middleware_home\Oracle_FRHome1\jdk\bin\jar -cvf olsardc.ear *

For example:

C:\mycustomloc>C:\app\oracle\middleware\Oracle_FRHome1\jdk\bin\jar -cvf olsardc.ear *

9. Copy the new olsardc.ear file to the upload directory middleware_home\user_projects\domains\OPADomain\servers\AdminServer\upload.
For example:

C:\mycustomloc>copy /Y olsardc.ear C:\app\oracle\middleware\user_projects\domains\OPADomain\servers\AdminServer\upload

Note:
Copy the new olsardc.ear file to the same location as the one entered in the Source path field.
To find the source path, go to the administration server console for the OPA domain. Click Deployments. Select the checkbox for olsardc and then click Update. After confirming the source path, click Cancel to exit the Update Application Assistant screen.

D.3 Deleting the Existing Deployment

1. Log in to the administrator server console for the OPA domain using a URL of the form http://machinename:port/console.
For example, http://phrama.company.com:7101/console

2. Click on Deployments.

3. Select the checkbox for olsardc, select it and click Stop, then click Force Stop Now.

4. Select the checkbox for olsardc one more time and click Delete.
If you are prompted to proceed with the deletion, click OK to confirm.

Note:
This removes olsardc.ear from the application server.

D.4 Redeploying RDC with Customizations

RDC application files are inside the olsardc.ear archive, so whenever you make changes to a file, you need to redeploy RDC for these changes to take effect.

Redeploy RDC if you have applied any of the following customizations:

- Setting Web Command Access

- Customizing the Electronic Signature (Approval) Warning Message

- Customizing Online Help

- Made changes to the bc4j.xcfg file for performance customizations, as described in the section ”Updating the bc4j.xcfg Settings” in the Oracle Clinical Remote Data Capture Onsite and Oracle Thesaurus Management System Browser Infrastructure Tuning Tips for Releases 5.0.1 and 5.1, available on My Oracle Support (Article ID 1965232.1).

To redeploy RDC:

1. Log in to the administrator server console for the OPA domain using a URL of the form http://machinename:port/console. For example, http://pharma.company.com:7101/console.

2. Click on Deployments and select the olsardc checkbox.

3. Click Update.

4. Click Next.

5. Click Finish to complete the deployment.

6. Restart the OPA server.

D.5 Restarting the OPA Server

Upon redeployment, you need to restart the OPA server so that any changes.

1. Log in to the administrator server console for the OPA domain using a URL of the form http://machinename:port/console.

2. Click on Environments and then Servers.

3. Select the Control tab.

4. Select the checkbox for OpaServer1.

5. Click on Shutdown and then Force Shutdown Now.

6. Refresh the screen by clicking on the auto refresh icon.

7. Once the status of OpaServer1 changes to SHUTDOWN, click on the auto refresh icon again to turn it off.

8. Select the checkbox for OpaServer1 and click Start.

9. Turn auto refresh on again to verify that the server status changes to RUNNING.

Once the OPA server is restarted, you can verify your customizations.

Glossary

access

A property of a user name that denotes that certain privileges have been granted to that user. The term is used in RDC documentation as a means to convey that a set of privileges have or have not been granted to a particular user.

active

A discrepancy status that indicates the relevant discrepancy is actionable by members of your user group.

approval history

A record, or set of records, associated with a CRF that lists each change in approval status starting with the initial approval action.

approval status

A designation that describes the current state of approval for a CRF. RDC has four approval statuses:

- not approved

- approved

- approval undone

- awaiting re-approval

See also discrepancy status; entry status; verification status.

approval undone

An approval status that indicates a user with the approve privilege has removed the approved status of a CRF via the Undo Approval action.

approved

An approval status assigned to a CRF that indicates a user with the approve privilege certifies that the CRF is an accurate representation of the source data. In RDC, an approval is equivalent to an electronic signature.

audit history

The set of all audit records for a given data point.

See also audit record; data point.

audit record

A set of information that describes an instance of data update. Each audit record includes the following information:

- The current value of the data point

- The previous value of the data point

- The user name that changed the data point

- The time stamp the data update occurred

- The change reason

- An optional comment

awaiting re-approval

A system-generated approval status that indicates the CRF is approved, but that one or more response values were updated. A CRF in this approval status can be re-approved or the approval can be undone.

The CRF changes that cause the change in approval status include:

- Response value update

- Update to an investigator comment

- Initiation of a new investigator comment

- Update to a discrepancy

- Initiation of a new discrepancy

awaiting re-verification

A system-generated verification status that indicates the CRF is verified, but that one or more response values were updated. A CRF in this verification status can be re-verified or the verification can be undone.

The CRF changes that cause the change in verification status include:

- Response value update

- Update to an investigator comment

- Initiation of a new investigator comment

- Update to a discrepancy

- Initiation of a new discrepancy

batch loaded data

A designation that specifies response values were entered into a CRF by electronic means, as opposed to manually entered via a user performing data entry.

blank

An RDC entry status designation that is assigned to a CRF a user has defined as blank. A Blank CRF does not contain data, nor can data be collected while it is marked as blank.

blank flag

A check box in the Data Entry window. The Blank Flag, or check box, is used to designate a CRF as blank. It is a standard item in the CRF Header area of a Data Entry window and may also be present in the CRF Section, especially in multi-section CRFs.

book

See casebook.

browse (user action)

A user action that entails reviewing existing data without adding new data or changing existing data.

cancel

A user action that halts the current process or action and reverts to the state of the application that immediately preceded the process or action, without changing the status of the system or data.

Cancel button

In a dialog box or window, the Cancel button causes the application to dismiss the window, disregard changes made in the window, and revert to conditions that existed before the window opened.

casebook

A collection of phases, patients, visits, and CRFs within a study.

case report form

See CRF.

change history

A listing of the values that have been assigned to data or information. Each list item includes information that uniquely identifies it. Specifically, a time stamp and the user name of the person who made the change are recorded. In RDC, a change history can be associated with the following:

- response value

- investigator comment

- discrepancy

change reason

A constituent of an audit record. A standardized entry that explains why a data point changed. The change reason can be supplied either automatically (system-provided) or manually (user-provided).

clinical planned event

An occurrence, usually a visit, that is scheduled as part of a protocol to collect clinical data for a patient. In RDC, visits appear in the context of a casebook.

closed

A discrepancy status that indicates the relevant discrepancy is not actionable by any user group. The discrepancy has been resolved, either by a user or the system.

See also active; discrepancy state; discrepancy status; obsolete; other.

PE

See clinical planned event.

created

An RDC entry status designation that is assigned to a CRF when all required CRF header data has been entered and saved, and no other data (that is, response data) has been entered.

This is used when your internal process involves an administration person who logs the paper as received in-house, but the data have not yet been entered by the data entry staff.

CRF

Case Report Form. A paper or an electronic record associated with a patient in a clinical study. Its purpose is to facilitate accurate collection of clinical data. RDC displays CRFs in the Data Entry window.

criterion

In reference to the RDC Search window, one of the components that can be altered so that a certain set of study data is retrieved. Each criterion is comprised of a set of parameters that allow you to make choices about the data you want to retrieve.

CRF header

A component of a CRF as it is displayed in the Data Entry window. It consists of one or more header fields, in which you collect information that uniquely describes and defines the current CRF.

RDC will not save a CRF to the study database until all required CRF header and CRF section header fields are collected.

CRF section

In RDC, a constituent of a CRF that is comprised of a set of related questions. Each CRF contains at least one section and may contain more than one. In Oracle Clinical terms, a section equates to a data collection module (DCM).

current

A discrepancy state that indicates action can be taken on the discrepancy – either by a user or by the system. It has not been made obsolete by the system.

See also active; closed; discrepancy state; obsolete; open; other.

current study

The data set that is active in RDC. The name of the current study is displayed in the title bar of the Main Application window.

data collection instrument (DCI)

See DCI.

data collection module (DCM)

See DCM.

data entry mode

In RDC, a designation that describes the method that is used to enter data into a CRF and save it to the study database.

data entry status

A designation that describes the current state of data entry for a CRF. RDC has four data entry statuses: created, blank, entry started, and entry complete.

data field

A location in the Question area of the Data Entry window in which you type a value that is the response to a CRF question.

data point

A location in a form where a data value may be entered. In most cases, a data point corresponds to a field in the Data Entry window.

data update

In RDC, the process of changing a CRF that has been created and saved to the database by altering a data point and saving the new version of the CRF to the database.

See also CRF; created; data point; initial data entry.

DCAPI

Data Capture Application Programming Interface.

DCI

Data Collection Instrument. The term that Oracle Clinical uses for an RDC CRF. A DCI is composed of one or more DCMs.

See also CRF; DCM.

DCM

Data Collection Module. The term that Oracle Clinical uses for a CRF section (CRF).

In Oracle Clinical, a DCM is a set of one or more related groups of questions that pertain to a single clinical study visit.

See also section (CRF).

default study

The preferred study associated with your user name. RDC automatically selects the default study when you start a session.

- If you have access to one study, that is your default study.

- If you have access to more than one study, the study that was active when you closed the previous session is the default study.

- If you have access to more than study, but have not started a previous session in the current database, the system administrator can specify a default study.

- If the a default study is not specified, the system presents the Change Study window when you log in, which lets you select a study from among those to which you have access.

discrepancy

Data that falls outside of an expected range of values or is otherwise flagged during the edit check process.

See also discrepancy management; manual discrepancy; multivariate discrepancy; univariate discrepancy.

discrepancy action

A process that changes the status of a discrepancy. There are two types of actions:

- Routing

- Resolution

discrepancy change history

The listing associated with a discrepancy that provides details of each update that was made it. The specific components of the discrepancy change history that are available to RDC users are:

- Time stamp of update

- Error text

- Discrepancy comment

- Current status

- Resolution

- Resolution comment

- Change by

discrepancy management

A process that systematically addresses discrepancies generated within a study. Discrepancy management attempts to identify the cause and assess the implications of each discrepancy and determine an appropriate action for the discrepancy. Its goal is to satisfactorily resolve all discrepancies associated with each CRF.

See also discrepancy; manual discrepancy; multivariate discrepancy; univariate discrepancy.

discrepancy record

An entry that is part of the study database that defines the pertinent aspects of a discrepancy, from its initial occurrence and through each action that is taken on it.

discrepancy state

The highest level designation of a discrepancy. A discrepancy can be in one of two states: current or obsolete.

discrepancy status

A designation that describes a current discrepancy or the current state of a CRF with regard to discrepancies. RDC has four discrepancy statuses: active, other, closed, and none.

discrete value group

See DVG.

document

In RDC, the equivalent of a CRF.

document number

A system-assigned unique identifier for a particular collected CRF.

DVG

(Oracle Clinical) A set of responses that are acceptable for a given question. A DVG constrains the responses to a question to a distinct set of values. It may also allow the same question to be used in multiple instances.

It is also possible for one DVG to be a subset of another DVG. In this case, the child DVG is made up of responses that are part of the parent.

entry complete

An entry status that is assigned to a CRF in which all required fields have been entered, including CRF header fields and Question area response data points.

entry started

An entry status that is assigned to a CRF in which data entry has been started but is not complete. CRFs that are assigned this entry status, some required data fields are complete, while some are not; the document has been saved in an incomplete status.

entry status

Formal stages of data entry, delineated in Oracle Clinical and RDC, that track the progression of a CRF from no data entered (created) through entry complete, to approved.

See also blank; created; entry complete; entry started.

focus

In RDC, where the cursor is currently active. Focus may change from window to window, as when the cursor moves from the application page to the first field in the Data Entry window.

How focus changes is a consideration when you are modifying the settings on the Preferences window to enhance the efficiency of your data entry or verification and approval sessions.

frozen

A designation that is applied to a patient that indicates that all data has been received, entered, reviewed, and cleaned for the patient, CRF, or visit.

header field

A location in the CRF Header or the CRF Section Header in which you collect values that provide information about the CRF. A header field is either required or optional. All required header fields must be collected before the system permits a CRF to be saved to the study database.

In the CRF Header, the following header fields are available:

- Visit date

- Visit time

- Comment

- Blank flag

In CRF Section Headers, the following fields are available:

- Date

- Time

- Blank flag

- Clinical planned event

- Lab

- Qualifying value

Note: The preceding lists are specific to RDC only.

indicator question

A question used with a question group that allows branching during data entry based on the response.

For example, in a Drug Allergy question group, an indicator question could be, "Allergic to any drug?"

- If the response is Yes, the remaining questions in the question group, such as Drug Name and Type of Reaction, require responses.

- If the response is No, the rest of the question group is not collected.

initial data entry

The step in the RDC workflow during which the CRF is initially opened and created. During this process all required CRF and CRF section header information is collected. Response data may or may not be collected.

installation reference codelist

(Oracle Clinical) A reference codelist that is defined and populated upon initial installation of the application.

instance

An application server instance is the set of processes required to run the configured components within an application server installation. There can be only one application server instance per application server installation. The terms installation and instance are sometimes used interchangeably; however, it is important to remember that an installation is the set of files installed into an Oracle home and an instance is a set of processes associated with those files.

internal

A discrepancy status that can be assigned to a section discrepancy through a routing action. This type of discrepancy can be configured so that it is hidden from one or more user groups.

investigator comment

A textual explanation that is written by the investigator. It provides the investigator with the opportunity to include additional information with a response value. Each investigator comment is saved as part of the response with which it is associated.

RDC provides visual cues to alert the user to the presence of an investigator comment associated with a data point:

- The Data Entry window displays the response field with a yellow background.

- The Data Entry window displays the data value in a green font.

- When focus is in the relevant response field, the title in the Data Entry window includes an <Inv> entry to indicate the presence of the investigator comment.

list of values

A set of possible values for a data field. The list of values can generally be displayed by clicking the button that is associated with list of value fields, clicking the List button, or pressing the F9 key.

Values that are defined for a discrete value group are displayed as a list of valid values.

See also discrete value group.

lock process

A process that prevents subsequent update of a CRF. Under most circumstances, a locked CRF cannot be unlocked, although administrators may permit, on a limited basis, a user to unlock a single CRF so that data may be updated.

locked

A status assigned to a CRF that indicates all data has been collected, approved, and verified. A locked CRF may be viewed in browse mode and may be included in PDRs, however, its data may not be updated under normal circumstances.

See also browse mode; lock; PDR; status; update mode; unlock.

lock status

A designation that describes the current state of a CRF, with regard to whether or not it may be updated. RDC has two lock statuses: locked and unlocked.

LOV

See list of values.

mandatory response field

A response field in the question area of CRF section that should be completed before the CRF is saved in the Entry Complete status. Failure to do so results in the generation of a discrepancy, which is associated with the relevant response field.

mandatory field discrepancy

A discrepancy associated with a mandatory response field that is generated by the system when a CRF is saved. The discrepancy triggers when data for the field is not collected.

manual discrepancy

A discrepancy that is generated by a user, rather than a data point value. In RDC, a manual discrepancy may be associated with an entire CRF, a CRF section header, or a specific response in the question area of a CRF.

See also discrepancy; discrepancy management; section discrepancy.

multivariate discrepancy

A discrepancy that is dependent on two or more data point values, which can be within a single CRF or across multiple CRFs and/or visits. A multivariate discrepancy is generated when a CRF is saved, which causes the system to run the validation procedures that locate this type of discrepancy.

See also discrepancy; discrepancy management; manual discrepancy.

news item

A message that is communicated by the study sponsor to some portion of its RDC users.

non-repeating question group

A set of questions that are related, but for which there is not a single set of possible answers.

See also question group; repeating question.

not approved

An approval status assigned to a CRF that indicates the CRF has never been approved.

See also approval status; approved; awaiting re-approval; not approved.

not verified

A verification status that indicates the CRF has not yet been verified.

See also awaiting re-verification; not verified; verification status; verified.

obsolete

A system-generated discrepancy state assigned to a discrepancy that is associated with a response that is a constituent of:

- A repeating question row that was deleted

- A question that was deleted

- A CRF section that was deleted

- A CRF that was deleted

A section discrepancy is made obsolete when its parent CRF is deleted or made blank. A data discrepancy is also made obsolete if the validation procedure upon which it is based is retired.

OC4J Location

Refers to the folder location where the OC4J instance under which the RDC application is running is installed.

Oracle Application Server Containers for J2EE (OC4J) is a complete set of J2EE containers written entirely in Java that execute on the Java Virtual Machine (JVM) of the standard Java Development Kit (JDK).

OC4J Restart

RDC runs under a specific OC4J instance called rdc created under AS10g during installation. Restarting this OC4J involves going to the AS10g administrative console (Web or command prompt), locating this particular OC4J instance, and restarting it.

OPA_HOME

An environment variable (UNIX) or registry key (Windows) that indicates the directory where Oracle software is installed. For RDC, OPA_HOME refers to the location of the OLSA home folder, which includes subfolders containing binaries, logs, temporary files, and configurations.

open

A designation for a discrepancy that indicates it is either in the active or other discrepancy status; that is, it is actionable by a user group.

A designation for a CRF that indicates it contains at least one active or other discrepancy.

optional CRF

A CRF that is planned in a visit, but that the protocol does not require to be collected. Optional CRFs are not included when the system determines whether there are missing pages. The information in the CRF Column Header of optional CRFs is displayed in italic font to distinguish each from required CRFs.

other

A discrepancy status that indicates the discrepancy is actionable by a user group other than yours.

parameter

In reference to the Search window, a component of a criterion that you use to define a specific property of the data you want to comprise the workset. A parameter may be comprised of settings that represent a value or range of values that, when combined with any other parameters in the same criterion, define specific data.

See also criterion; search phrase; setting.

pass 2 complete

A data entry status that assigned to CRFs that originate in the Oracle Clinical data entry system. It indicates that two-pass data entry was required for the CRF and that the second pass is complete.

pass 2 started

A data entry status that assigned to CRFs that originate in the Oracle Clinical data entry system. It indicates that two-pass data entry was required for the CRF and that at least one response field has been recorded in the second pass.

patient

The data that represents a participant in a clinical study. This includes demographic information and clinical results.

Patient Data Report (PDR)

A generated compilation of data that is presented in a PDF document.

patient list

The set of patients that contain at least one CRF that satisfies the search criteria.

patient number

A designation for a set of patient data that is unique across a given study. Patient numbers are assigned to a study as part of the Oracle Clinical Design process. Alternative terms include: enrollment number, allocation number, and randomization number.

The following rules apply to all patient numbers:

- Each patient number must always be assigned to a site.

- Each patient number may not be assigned to more than one site at a time.

- The first character in the patient number string may be a non-zero numeric or an alphabetic character.

- If the first character in the patient number string is alphabetic, the second character must be a non-zero numeric character.

- Only the first character may be alphabetic.

PDF

Portable Document Format. A universal file format published by Adobe Systems, Inc., that preserves all the fonts, formatting, graphics, and color of a source document that is generated with any application on any operating system.

pending changes

Changes that are made to a CRF that have not yet been committed to the study database. The changes that may be pending are response value, investigator comments, or discrepancies. The save action commits pending changes to the database.

phase

An attribute of a book that denotes a stage of a study. Phases are used to divide the study into logical groupings of visits. Examples of phases include: Screening, Dosing, and Follow-up.

Portable Document Format

See PDF.

privilege

A privilege is the right to perform an action on the database. Privileges can either be general (system privileges) or specific to particular database objects (object privileges). They can also be grouped into roles.

The ability for an RDC user to perform a certain task. Privileges are granted to users in the RDC Administration study and site maintenance windows by administrators. In general, users within a user group, that is, those that are given the same role, are assigned the same set of privileges.

The following privileges may be assigned to RDC users:

- Browse

- Browse batch loaded data

- Browse Source Data Verification Plan

- Update data

- Update batch data

- Update discrepancies

- Update Source Data Verification Plan

- Administrate Source Data Verification Plan

- Verify CRFs

- Approve CRFs (on a site basis only)

- Lock

- Unlock (on a site basis only)

qualifying value question

A question that differentiates between sets of identical questions. In a multi-section CRF, where the same section, containing the same set of questions, is collected more than once, a qualifying question is used in each such section. The purpose of the qualifying question is to elicit a unique response, called a qualifying value, which allows differentiation of the responses in the sections.

When you respond to a qualifying value question, you select from a discrete set of values that are specified in the question definition.

An example of a qualifying question is a multi-section CRF that collects vital sign data multiple times in a single visit. Each set of vital sign data comprises a section. Each section is differentiated by "time post dose" question. The result is a set of vital signs collected at specific times.

qualifying value

The value assigned to a qualifying value question that is associated with a CRF section. For multi-section CRFs, where each section includes a qualifying question, the qualifying value is used to differentiate between the sections.

query

A procedure that is run against a database with the goal of returning a subset of a data that satisfy the query criteria.

An industry term that is a synonym for the Oracle Clinical term, discrepancy.

question definition

The set of information that delineates what data a question collects. Among the information is:

- Question name

- Data type

- Length

- Lower bound

- Upper bound

question group

A set of questions in a CRF that are related due to similarity or study protocol considerations.

An example of a question group is Demographics, which collects such data as gender, race, and birth date.

See also non-repeating question group; repeating question.

question name

The label that describes a question. It may be in the form of a question or it may simply be a word or phrase that serves as the prompt for a response.

RDC

Remote Data Capture.

repeating question

A question that usually consists of more than one response. The responses are generally situated in a single row and are referred to as a repeating question row. For each response, there may be a default value, which is a system-provided value that entered automatically when you open the CRF. A repeating question is usually one of a set, each of which are distinguished by the initial response or by a question label.

An example is a question group titled, "Body Systems." Each repeating question row collects data about a different body system with three response values. The first response in each row identifies the part of the body, for instance, chest, or head. The next response in each row requires one of three values: Normal, Abnormal, or Not Done. If the response to this question is Abnormal, the third response, Explanation, is required.

See also non-repeating question group; question group.

required CRF

A CRF that the protocol specifies as a planned CRF in a visit, for which data must be collected. Planned CRFs are analyzed when the system determines whether there are missing pages. The information in the CRF Column Header of optional CRFs is displayed in regular font to distinguish each from optional CRFs.

See also CRF; optional CRF.

required field

A designation for a CRF data point that indicates data must be collected for that field before the system will save the CRF.

resolution

A type of discrepancy action that causes the status of the discrepancy to change from active to closed.

See also discrepancy; discrepancy action; discrepancy status; routing; user role.

resolution reason

A parameter associated with a discrepancy action that provides a sponsor-defined reason when a user closes a discrepancy.

response value

The value that is assigned to a data point. This term usually refers to fields in the Question area of a CRF.

See also CRF; data point.

role

See user role.

routing

A type of discrepancy action that causes the status of the discrepancy to change from active to other for your user group and from other to active for a different user group.

See also discrepancy; discrepancy action; discrepancy status; resolution; user role.

search criteria

The settings that determine the CRFs that comprise the workset. These settings can be defined directly in the Search pane, or indirectly, through an Activities link.

search phrase

The group of settings that, when taken together, define a searchable property. For example:

Search all CRFs named Vitals that have active discrepancies.

You use several drop-down lists in the Search window to construct the search phrase.

section (CRF)

In RDC, a constituent of a CRF that is comprised of a set of related questions. Each CRF contains at least one section and may contain more than one. In Oracle Clinical terms, a section equates to a data collection module (DCM).

section (Graphical User Interface)

In the user interface, a section is a part of a window or other informational feature that contains related information and/or data fields. It is often delineated by a descriptive label and a border that surrounds its related components.

section discrepancy

A user-generated discrepancy that is associated with a CRF section. There can be multiple discrepancies associated with a CRF section. This is the only type of discrepancy can be routed as an internal discrepancy.

See also CRF section; discrepancy.

session

The period that starts when you successfully log in to RDC and ends when you exit RDC. This is also referred to as an RDC session. It is constricted by limitations that are imposed by the following conditions:

- Only one user name is granted access to a session.

- The role and privileges assigned to the user name determine the patient data and functionality that is available within a session.

- Only one database can be accessed during a given session. If you want to access a different database, you must start a new RDC session.

- Only one study can be open at a time during a session, however, unlike the restriction on the active database, you can change to another study within an RDC session. If you want to access a different study, you must close the current study and select another one.

- Only one book can be active at a given time, however, you can change to another book within an RDC session.

- One or more sites can be active during a given session and the privileges assigned to the user name may vary from site to site.

setting

The value of a parameter in the Search pane, which is a contributor to a the value of a criterion. Usually, the default setting for a parameter is ALL, which means that the parameter does not limit the data that is retrieved. When the value of a parameter is set to something other than ALL, it generally limits the number of CRFs that are retrieved.

See also criterion; parameter.

shortcut key

A key or key combination that allows you to implement a function in the application by using the keyboard.

test mode

A method of using RDC during study design, prior to the start of the protocol. Under normal circumstances, RDC runs with Production mode active. This mode mirrors the look and feel of production mode but uses a separate set of tables to store the data.

time point

A significant event in the history of a CRF. Used as criterion when viewing the Audit Trail tab. Examples of time points include:

- Creation date

- Verification dates

- Approval dates

time stamp

A value assigned to a data point that provides a chronology for significant events during a study. Such events include the date/time when a value was created, the date/time when a value was updated, and so on.

Uniform Resource Identifier

See URI.

Uniform Resource Locator

See URL.

univariate discrepancy

A discrepancy that is dependent on the value of a single data point. This type of discrepancy is usually when the value recorded for a response does not meet certain criteria that is deemed acceptable by the study sponsor.

See also discrepancy; discrepancy management; manual discrepancy; multivariate discrepancy.

unlock process

A process that allows a user with unlock privilege to assign to another user the capability to update a CRF that is in the locked status.

unlocked

A lock status that indicates a CRF may be updated.

unplanned

A designation attributed to any event or CRF that was not part of the protocol schedule or which occurs at a time other than was originally specified in the protocol schedule.

See also unplanned CRF; unplanned visit.

unplanned CRF

A CRF collected at a visit at which it was not planned, that is, it is not part of the casebook.

unplanned visit

A clinical event which occurs that was not scheduled by the protocol.

update process

A process or condition in which CRF data or information, which has previously been saved, is changed.

URI

Uniform Resource Identifier. The generic term for all types of names and addresses that refer to objects on the World Wide Web. A URL is one kind of URI.

URL

Uniform Resource Locator. An Internet address that points to a specific resource on the World Wide Web by its location. The address is described in combinations of syntax and special characters that, when combined, represent a unique string. In general, URLs make up a subset of URIs. Common URLs are those that point to Web pages or to FTP sites. The former are identified by an "https:" or "http:" prefix string, the latter are identified by an "ftp:" prefix string.

Uniform Resource Locator (URL), a form of URI, is a compact string representation of the location for a resource that is available via the Internet. It is also the text-string format Web clients use to encode requests to Oracle Application Server.

user role

A role is a group of database privileges that can be granted and revoked as a unit. Specific privileges can be granted and revoked from the role dynamically, and the role can be enabled or disabled dynamically for specific users.

In RDC, there are five default user roles, however, any given study database may include some or all of these, and may include sponsor-specific roles. RDC allows privileges to be assigned independently of user role assignment.

The roles that RDC ships with are:

- Super User (SU)

- Data Manager (DM)

- Clinical Research Associate (CRA)

- Site Coordinator (SITE)

- Site Investigator (INV)

See also privilege.

Note:
The RDC documentation uses this default set of user roles to describe various functionality that is dependent on certain sets of privileges.

validation

An action that entails the initiation and processing of sponsor-defined procedures, in the case of multiple data points, or edit checks, in the case of a single data point, that analyze collected data and return an query, or discrepancy, for each data point that does not meet the criteria defined in the procedure. Such a data-generated discrepancy is also referred to as a validation error.

validation error

A condition associated with one or more data points that indicates the value does not meet the criteria defined in a question definition or validation procedure. It is equivalent to a data-generated discrepancy.

value

When used in the context of criteria and parameters, the choice that you assign to a parameter, which was chosen from a list of possible values.

verification history

A record, or set of records, associated with a CRF that lists each change in verification status starting with the initial verification action.

verification status

A designation that describes if a CRF has been verified. RDC has four verification statuses: not verified, verified, verification undone, and awaiting re-verification.

verification undone

A verification status that indicates the CRF was verified but subsequently the verification was undone. This status is equivalent to the not verified status, with the exception that a verification history exists for a CRF in verification undone status.

verified

A verification status that indicates the CRF has been verified by a user with the verify privilege.

verify

A privilege assigned to a user name that allows the user to alter the verification status of a CRF or a group of CRFs. The privilege can be assigned at the study level or the site level.

visit

A clinical event, which generally denotes the occurrence of a meeting between a patient and clinical staff at a study site. In the course of a visit, data related to the study is collected, which at some point is recorded and saved to the study database.

In RDC, a visit consists of one or more CRFs.

watermark

A visible feature that overlays a browse mode CRF in the Data Entry window. It displays the time stamp of the last modification and the words BROWSE ONLY. The browse mode watermark is visible along the left-hand margin of each CRF page.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Pre-General Availability Draft Documentation Notice

If this document is in public or private pre-General Availability status:

This documentation is in pre-General Availability status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Pre-General Availability Draft Documentation Notice

If this document is in private pre-General Availability status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your pre-General Availability trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.