3 Configuring Discrepancy Management

3.1.1 Specifying User Roles for the Oracle Clinical Discrepancy Database

In the USER GROUPS installation reference codelist, you specify which of the roles mapped to database roles in the USER GROUP ROLES reference codelist will be available for use in customizing aspects of the discrepancy management system in Oracle Clinical, including profiles and layouts for use in the Maintain Discrepancy Database window.

The position of a database role in the codelist is important if users have more than one database role. In the case of a user with more than one role, the system uses the database role closest to the top (seq=1) in the codelist as the default; for example, as the default profile when the user opens the Maintain Discrepancy Database window.

The long value is not used.

3.1.2 Assigning Function Privileges and Layouts

You control user group discrepancy function privileges and layout definitions in the User Group Admin window. From the Admin menu, select Discrepancy Mgmt, then select User Group Administration.

The window displays a list of existing user group names and their mapped database roles. Select a user group name to view its defined function privileges and layouts.

3.3.1 Toggling Between View Modes in the Profile Administration Window

To open the Profile Administration window:

1. Navigate to Admin, Discrepancy Mgmt Admin, and then select Profile Administration.

   The Profile Administration window has two viewing modes: multi-view and single-view. The window opens in multi-view mode by default.

   In multi-view mode, you can view all the profiles currently defined. In single-view mode, you view one profile at a time. In either mode, you can create new profiles and specify the criteria for each profile.

2. Click the View Mode button in the upper right corner of the form to toggle between multi-view and single-view mode.

3.3.2 Specifying Default Profile Criteria

You can refine a profile group's view by specifying default profile criteria values in the Profile Administration form. Many of the fields have lists of values. If you do not specify a particular criterion, the system allows a user with that profile to query all possible values. If you do not lock a profile criterion (see the following section), users can override the Master profile's default settings.

3.3.3 Locking Profile Criteria

Profile users can customize their profiles, and thereby modify their views of the discrepancy database. You control the extent to which they can modify a profile by locking or unlocking each criterion. The locks are boxes that, in single-view mode reside between each criterion name and its field, and in multi-view mode reside to the right of each criterion's field. (See Figure 3-1 and Figure 3-2 for examples of each view mode, with diagonal arrows indicating the box positions.) The lock prevents users from modifying the default profile settings. If you do not lock a profile criterion, a profile user can override the profile's default setting.

In multi-view mode, for criteria like Accessible Data Only? where toggle boxes control viewing, the Lock box is to the right of the criteria names. (See Figure 3-1.)

In single-view mode, for criteria like Accessible Data Only? where toggle boxes control viewing, the Lock box is to the left of each criterion's toggle box. (See Figure 3-2.)

Figure 3-1 Sample Multi-View Region of the Profile Administration Form

Description of ''Figure 3-1 Sample Multi-View Region of the Profile Administration Form''

Figure 3-2 Sample Single-View Region of the Profile Administration Window

Description of ''Figure 3-2 Sample Single-View Region of the Profile Administration Window''

In single-view mode, for criteria like Accessible Data Only? where toggle boxes control viewing, the Lock box is to the left of the toggle box.

3.3.4 Adding SQL Statements

In addition to defining access to discrepancy details in the Profile Criteria fields, you can further limit data access by entering SQL statements in the SQL Text section. To prevent users from bypassing the SQL statements, check the locking box for each entry. (In single-view mode, the locking box is to the right of the SQL Text label. In multi-view mode, the locking box is to the left of the SQL Text column's fields.) Your SQL statements have a size limit of 2000 characters.

3.3.5 Filtering Profile Views by Review Status

You can limit a profile's view of discrepancy records according to the records' current review status classifications. Select a profile in the Profile Administration form, then click the Review Status button to open the Discrepancy Review Status Codes dialog box. (To define the codes you see in this box, see "Defining the Possible Review Statuses for Discrepancies".) The dialog box contains rows with three columns: the Selected? box column, the Status Name column and the Locked? box column.

Each Selected? box controls a profile's default access to records that have that review status classification code. Select a code's Selected? box to include discrepancy records; deselect it to prevent viewing records with its code.

Users can override each of these settings in their personal profiles unless you lock them. If you lock a review status code, profile users cannot override the profile's default setting.

The following table describes the outcome for the four possible combinations of Selected? and Locked? boxes.

3.3.6 Updating Status Codes

If the values in the DISCREPANCY REV STATUS CODE reference codelist change, you can update all profiles with the new values by clicking the Add Review Status button. (To edit the codelist, see "Defining the Possible Review Statuses for Discrepancies".)

3.3.7 Filtering Profile Views by Discrepancy Field

You can control a profile's access to discrepancy review status types and individual discrepancy fields by setting its privileges. By default, a new profile has no update privileges; you must add review status codes, and then discrepancy field values to each master profile. To open the Privileges for DM Master Profile window, from the Admin menu, select Discrepancy Mgmt Admin, and then select Profile Administration. Select a master profile, then click the Privileges button.

3.4.1 DISC_FLEX1 and DISC_FLEX2

Use these local reference codelists to customize the label for Flexfield1 or Flexfield2, to enable the field, to make the field mandatory or not, and to specify whether or not there is a list of values for the field.

3.4.2 DISC_FLEX1_VALUES and DISC_FLEX2_VALUES

If you set LOV_VALIDATE to Y in DISC_FLEX1, you can create a static list of values by entering each allowed value in a row in this codelist. When a user displays the list of values in the Discrepancy Database window, the system displays the short value and description for each row you enter here. (Alternatively, create a dynamic list of values; see "Customizing Flexfields".)

The long value is used as the description in the Flexfield1 (or 2) field's list of values. The short value is stored in the FLEX_FIELD1 (or 2) column in the DISCREPANCY_ENTRIES table in the database. The default value has no effect.

3.4.3 Example

To customize Flexfield1 to ask the creator of a manual discrepancy record if the record is finished, and test the response entry against a list of three values, you would set the flexfield1 codelist values to the values in the following two tables, with the three values defined in the second. (Values that differ from the default values are in italics.)

3.5.1 Reason Codes and Descriptions for Manual Discrepancies

When a user creates an Operator Comment (a manual field or section discrepancy in RDC Onsite), the system prompts the user to select a reason code from a list of reasons that is populated by the MANUAL SOURCE TYPE CODE reference codelist in Oracle Clinical. The user can also enter an additional explanation for the discrepancy.

You can add and remove values in the reference codelist (see Figure 3-3):

• For each reason you add, enter a value in the Short Value field and the Description field.

• Set one reason to Default. The first time the user creates a manual discrepancy during a login session, the system inserts the default reason. The user can select a different reason. For subsequent manual discrepancies, RDC Onsite displays the last entered reason. The user can always select a different reason.

Oracle Clinical stores the short value in the database.

Figure 3-3 Defining Reasons for a Manual Discrepancy

3.5.2 Reason Codes and Descriptions for Univariate Discrepancies

The system creates a univariate discrepancy when the data entered does not match the requirements defined in the underlying question, such as data type or length. You cannot change these underlying causes, but you can change the reason text or define more than one reason associated with a single underlying cause, from which the user can choose.

The system automatically populates the reason code and description when it raises the discrepancy.

To define reason codes and descriptions for univariate discrepancies:

1. Open Oracle Clinical.

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

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

• Text Type — Select COMMENT to specify descriptions for univariate discrepancies.

• Sub Type — Select from the list of valid univariate discrepancy types. RDC Onsite uses the text in the Sub Type field to populate the Reason field when a discrepancy of that type is raised.

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

• Default — If you choose to create a selection of multiple descriptions for a certain discrepancy type, select which description is the default value. RDC Onsite uses the default value the first time a discrepancy of that type is raised. The user can always select one of the alternative descriptions provided.

• Standard Text — Specify the description that you want RDC Onsite 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; for example:

  Value of \VALUE_TEXT\ for \SAS_LABEL\ is not a valid \DATA_TYPE\.
  

  where VALUE_TEXT is the data response entered, SAS_LABEL is the SAS label defined for the Question, and DATA_TYPE is the data type defined for the Question.

Figure 3-4 Defining Descriptions for Univariate Discrepancies

3.5.3 Reason Codes and Descriptions for Multivariate Discrepancies

Oracle Clinical raises multivariate discrepancies when user-defined validation procedures detect invalid or inconsistent data. You specify the reason for multivariate discrepancies in the procedure definition; see Oracle Clinical Creating a Study for details. Oracle Clinical displays the reason; RDC Onsite does not.

3.6.1 Default Entries for the DISCREPANCY REV STATUS CODE Codelist

The following table lists the entries in the DISCREPANCY REV STATUS CODE codelist following the initial installation of Oracle Clinical.

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.

There are additional statuses that are not included in the reference codelist:

OBSOLETE: When the data is no longer discrepant—either because the data is updated or because the validation procedure or question attribute that flagged the data as discrepant is changed in such a way that the data is no longer discrepant—the system automatically updates the system status to OBSOLETE.

PASSIVE REVIEW is a status that allows you to reduce the number of discrepancy queries and the number of discrepancies on a DCF by associating one or more discrepancies with a primary discrepancy. You can then include all the discrepancies in a single query. When you create the DCF, do not include discrepancies marked as Passive Review in the printed DCF.

For example, if you have a page with three lab results and all three lab results are missing, you would have three discrepancies such as:

• AST lab units missing, please provide.

• ALT lab units missing, please provide.

• RBC lab units missing, please provide.

You could send three queries, but to save time, money, and paper you could choose to send only one query such as: Page 7 all lab units are missing, please provide.

To do this, mark the second two discrepancies for passive review associated with the first discrepancy as the primary discrepancy. Then create a DCF, include all three discrepancies in the DCF, but mark the primary discrepancy's status as For Distribution and the other discrepancies' status as Not For Distribution. When you print the DCF, only the primary discrepancy appears, but all three are included in the electronic DCF. When the answer to the query returns, you can update the data for all three discrepancies.

3.6.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, whose initial review status is defined in the Details block of the Oracle Clinical validation procedure that generates the discrepancy.

• The Description field must be entered for each short value. In RDC, the system uses this value to display the status of discrepancies in any discrepancy management-related windows, forms, tasks tabs, or reports. In Oracle Clinical, the system uses the short value to describe the status of a 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.

3.9.1 Configuring Discrepancy Display by User Role

This section includes the following topics, which apply only to RDC:

• How RDC Indicates Discrepancies in the User Interface

• Rules for the DISCREPANCY STATUS role Codelists

• Comparison of the Default Values for the DISCREPANCY STATUS role Codelists

• DISCREPANCY STATUS CRA

• DISCREPANCY STATUS DM

• DISCREPANCY STATUS INV

• DISCREPANCY STATUS SITE

RDC uses the DISCREPANCY STATUS role installation reference codelists to determine how discrepancies with a particular status are displayed for users with a particular role. There is a different reference codelist for each default user role: CRA, DM, INV, and SITE. You can create a DISCREPANCY STATUS reference codelist for additional roles; see "Adding Reference Codelists for Custom Roles".

Use these codelists to ensure that discrepancies are displayed appropriately for users of different roles. 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.

Every status defined in the DISCREPANCY REV STATUS CODE codelist must be included in the DISCREPANCY STATUS role codelist for each role, with a long value that determines how the discrepancy is presented (or not) to the user. The possible long values are:

• ACTIVE: (For open discrepancies) The current user can take action against this discrepancy.

• OTHER: (For open discrepancies) The discrepancy is assigned to a user with a different role. For RDC Onsite, you can prevent users from taking action on OTHER discrepancies with the reference codelist DISCREPANCY NO OTHER UPDATE; see "Preventing Update to OTHER Discrepancies".

• CLOSED: (For closed discrepancies) System-closed discrepancies cannot be re-opened by users with any role. If the discrepancy was manually closed by a user, any user with UPDATE or UPD_DISCREP privilege can re-open the discrepancy.

• HIDDEN: (For open discrepancies) The current user cannot view or take action against this discrepancy. This functionality is intended only for section-type discrepancies. If a 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.

  There is another technique for hiding any type of discrepancy (section, univariate, multivariate) at a particular status (for example Internal DM Review) from a particular user role (for example SITE). In this example, simply uncheck the Active check box for the status Internal DM Review in the codelist DISCREPANCY STATUS SITE.

  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.

  Note:

  Long values must be in uppercase.

3.9.2 Configuring the Actions Allowed on Discrepancies

In RDC Onsite, 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 with a particular status.

Each DISCREPANCY ACTIONS role codelists specifies allowed actions for 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. You can create a DISCREPANCY ACTIONS reference codelist for additional roles; see "Adding Reference Codelists for Custom Roles".

To enable users of the relevant role to route discrepancies to a particular status:

1. In the Short Value field, enter the name of the discrepancy status—as it appears in the DISCREPANCY REV STATUS CODE codelist—to which you want users of the role specified in the reference codelist name to be able to route discrepancies.

   Note:

   The codelist must contain one and only one row with 'CLOSED' as a short value.

2. In the Long Value field, enter the Actions drop-down item text that should appear for users with the role.

3. Be sure the Active check box is checked.

   Note:

   To remove the item from the Actions drop-down list, uncheck the Active check box.

   The Description field is optional.

4. Save your work.

3.9.3 Preventing Update to OTHER Discrepancies

Only RDC Onsite 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; see "Configuring Discrepancy Display by User Role".

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

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

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.

3.9.4 Adding Reference Codelists for Custom Roles

Oracle Clinical ships with Discrepancy Actions and Discrepancy Status reference codelists for these roles: DM, CRA, INV, and SITE. If you have defined additional roles, you can create additional Discrepancy Actions and Discrepancy Status reference codelists for these roles.

Log in to SQL*Plus as RXC and run a script that includes the following statements to create a new Discrepancy Actions and a new Discrepancy Status reference codelist for your custom role:

exec opa_install.insertrc('DISCREPANCY ACTIONS custom_user_group_role', 'Y','60','15','INSTALLATION','CHAR','Discrepancy actions for custom_user_group_role','','','RXC');

exec opa_install.insertrc('DISCREPANCY STATUS custom_user_group_role', 'Y','6','15','INSTALLATION','CHAR','Discrepancy status groupings for custom_user_group_role','','','RXC'); 

The new reference codelists then appear in the Oracle Clinical user interface and you can add appropriate values.

3.10.1 Updating a Discrepancy

The study and site level UPDATE and UPD_DISCREP privileges work in conjunction with function profile privileges to allow a user to update discrepancies, as indicated in Assigning Privileges to a User for a Particular Study.

To grant a user the ability to update discrepancies, make sure the user is configured at the study and site level in one of the following ways:

• The user has no specific privileges at the study level or for the site. In this case, the user is assumed to have the UPD_DISCREP privilege for any study where generic access is defined. See "Granting Data Access to a Study."

• The user is assigned UPDATE or UPD_DISCREP privileges at the study level. If no privileges are assigned at the site level, then the study level privileges are inherited and allow the user to update discrepancies.

• The user is assigned UPDATE or UPD_DISCREP privileges at the study site level. Since site privileges take precedence over study privileges, if ANY privilege is assigned to the user at the site level, you must also assign the UPDATE or UPD_DISCREP privilege for the site.

See "Configuring Study and Site Security Privileges.".

3.10.2 Navigating to Data Entry

The Discrepancy Management system allows a user to navigate to data entry and browse or update data with the right combination of function privilege(s) and site-level BROWSE or UPDATE privileges, as described below.

In contrast to other study- and site-level security settings, only the site-level BROWSE and/or UPDATE privileges, together with the function profile privileges, affect a user's ability to browse or update data.

• To allow a user to update data:

  1. Assign UPD DATA ENTRY to the user as a function profile privilege.

  2. To allow the user to use Update Patient Data for all sites in a study, assign UPDATE at the study level. Then you can also assign appropriate privileges for every site in the study where you need to override the study-level UPDATE privilege if you don't want the user to be able to update data for some or all sites in RDC.

     OR

     To allow the user to update data from RDC for only some sites, explicitly grant RDC site-level privileges for those sites where the user needs to view and update data from RDC. These site-level privileges do not affect update rights in the Oracle Clinical Discrepancy Management.

     For details on study- and site-level privilege interaction, see Section 3.10.1, "Updating a Discrepancy".

• To allow a user to browse all data, but only update it for some or no sites, do one of the following:

  • Don't assign any privileges at the site level and assign BRWS DATA ENTRY as a function profile privilege. The user cannot update data for any site, only browse data.

  • With either UPD DATA ENTRY or BRWS DATA ENTRY as a function profile privilege, assign BROWSE at the site-level so that the user cannot update data for that particular site, only browse it. The user can still update data for other sites if he has the UPDATE privilege for those sites.

  • Assign BRWS DATA ENTRY as a function profile privilege and UPDATE at the site-level to allow the user to update data for that particular site only, but be able to browse data for all other sites.

3.11.1 Defining DCF Statuses and their Behavior

There are several Installation Reference Codelists that affect DCF Statuses. You can modify them to for your organization's needs.

DCF STATUS CODES The DCF Status reflects the stage in the review process of the DCF as a whole. Oracle Clinical comes with many review statuses defined in this reference codelist. You can make them inactive if you do not want to use them or create new ones, with the following limitations:

• You cannot make these statuses inactive: Sent, Received, and Closed.

• Do not make status Created inactive unless you also make it optional in the DCF OPTIONAL STATUS CODES reference codelist.

• Do not make statuses Incomplete, Part Received, or Received inactive if you want the system to automatically update the DCF Status when users update the status of individual DCF Pages.

• If you add a status, you must set its DISPLAY_SN, which determines the order in which the statuses can be set. If you adjust the DISPLAY_SN, you may need to adjust the DCF LOCK CONDITIONS and the DCF OPTIONAL STATUS CODES installation reference codelists, both of which refer to DCF Statuses by their number in the DCF STATUS CODES installation reference codelist.

DCF OPTIONAL STATUS CODES This installation reference codelist refers to the DCF Statuses listed in the DCF STATUS CODES reference codelist. The number in the Short Value column refers to the display number of the status in the DCF STATUS CODES codelist. (Note that the description is incorrect for numbers 7 and 8, which should be Incomplete and Part Received.)

All status codes referenced and active in this codelist are optional. All that are inactive or not entered here are mandatory, meaning that a DCF must be assigned to that status before it can be assigned a subsequent status, as defined in the Seq column. As shipped, only CREATED, SENT and CLOSED are mandatory (no rows exist with short values 2, 6, or 12).

To make a status mandatory if it is included in this reference codelist, uncheck its Active box.

DCF LOCK CONDITIONS This installation reference codelist determines what actions can be taken on discrepancies and DCFs where the DCF has a particular status. The Long Value refers to the number of the status in the DCF STATUS CODES codelist. As shipped, the codelist sets the following behavior, in order:

• Discrepancies belonging to a DCF whose status is Final (#4) or higher cannot be deleted.

• Discrepancies belonging to a DCF whose status is Ready (#5) or higher cannot be modified.

• DCFs whose status is Ready (#5) or higher cannot be deleted (unless the status exceeds or equals a status with a DISPLAY_SN of 1000; see last point).

• DCFs whose status is Ready (#5) or higher cannot be modified.

• DCFs whose status is #1000 or higher cannot be closed. Oracle recommends that you do not change DCF_CLOSE.

To stop enforcing any of these rules, set the Long Value to a high value. To change the DCF Status that prevents any of the actions described in the Short Value column, change the number in the Long Value column to the number in the DCF STATUS CODES codelist of the status you prefer.

3.11.2 Laying Out the DCF

Laying out the DCF's contents and arranging its fields includes the following tasks:

• Replacing the DCF Placeholder Graphic

• Modifying Codelist DCF REPORT LABELS

• Modifying the DCF Views

• Defining DCF Headers and Footers

See the "Default DCF Layout Diagram" for a geographic representation of the DCF's default values and their placements.

OPA views dcf_rpt_master and dcf_rpt_detail control much of the content and the appearance of DCFs. Local codelist DCF REPORT LABELS controls the report's label text. DCFs also include several unchangeable parameters, such as the Revision # and other values that print along the bottom of each DCF page.

Replacing the DCF Placeholder Graphic

Oracle Clinical includes a placeholder graphic file located, typically, in your installation's ..\OPArelease_number\oc directory, and named rxcdcf.bmp. You can replace rxcdcf.bmp with your own graphic file, but you must name it rxcdcf.bmp. Oracle recommends that your graphic does not exceed 200 pixels in height.

Modifying Codelist DCF REPORT LABELS The labels for the value fields of the DCF views correspond to their position on the report. The following table describes each of the columns on the report. For field labels, it identifies the codelist member in the DCF REPORT LABELS local codelist and their default table and column values.

^Footnote 1 Not a label

Modifying the DCF Views

The following tables describe all of the parameters in the two DCF report views. The view scripts for the DCF are in file rxcviews.sql. You can map other discrepancy values to the DCF parameters, or comment out the parameters to remove them from the DCF output. Note that if you remap parameters, you may have to change their labels (See "Modifying Codelist DCF REPORT LABELS".)

The following table describes the values of the DCF_RPT_DETAIL view, and its default data values. In DCF report printouts, the system draws a rectangular border around the output of this view, and may include more than one discrepancy's details.

Defining DCF Headers and Footers

You can define standard text headers and footers in the Standard Text Maintenance form (see "Creating New Standard Text"). You can define any number of standard headers and footers and designate one header and one footer as the default. When you create a DCF, the system assigns it the default header and footer. You can use the list of values in the Header and Footer fields to choose a different standard header or footer.

You can also modify the standard text of the header or footer by clicking the Text button in the main DCF screen and editing the displayed text.

Default DCF Layout Diagram

The following diagram shows the relative position of the labels (in bold font), and the default data values of a default DCF printout. The section between the rxcdcf.bmp graphic and the ruled rectangle contains most of the data defined in the DCF_RPT_MASTER view. The DCF_RPT_DETAIL view populates the contents in the rectangle. A DCF can accommodate the descriptions of more than one discrepancy on each page. The legend for the DCF layout diagram precedes the diagram itself.

3.11.3 Replacing the Placeholder DCF Logo Graphic

The Oracle Clinical Data Clarification Form (DCF) report includes a bitmap image on the cover page.

You can replace the default image with your own graphic or logo, or you can use a graphics application to redraw the image.

The source file for the bitmap image is at the following location on Oracle Clinical Reports Server installations:

OPA_HOME/oc/rxcdcf.bmp

You can edit the image locally and then copy it to your server.

3.11.4 Customizing and Upgrading DCF Reports

For DCF Reports, you can customize the following files:

• rxcdrptl.rdf

• rxcdrptp.rdf

These source files are located on the Forms Server in the following directory:

OPA_HOME/oc/admin

3.12.1 Creating New Standard Text

To create new standard text entries:

1. From the Admin menu, select Discrepancy Mgmt, then select  Standard Text Maintenance.

   The Standard Text Maintenance form opens, with columns for Text Type, Sub Type, Standard Text Name, a Default box, and a line for the standard text string.

2. Choose a text type. The text type identifies where the system uses the definition: In DCF headers or footers or discrepancy comments and Data Entry. The choices are: Comment, Footer, Header, Internal Comment, Resolution. For more information, see the introduction in "Creating Reusable Standard Text for Discrepancies and DCFs".

3. Choose a subtype only if you are creating an alternative univariate error text (you must have chosen a Text Type of Comment as well). See "Customizing Default Standard Text Entries". Choose the subtype corresponding to the univariate error type for which you are creating a standard text.

   For discrepancy comments, internal comments, and resolution comments, and DCF headers and footers, do not enter a subtype. If you do, the text will not be available for use even though it is successfully saved.

4. Name the entry in the Standard Text Name field. Each standard text definition must have a unique name. Users see the name and the text definition in the list of values for Comments, Internal Comments, and Resolution Comments of the Maintain Discrepancy Database.

5. Toggle the Default box. For the COMMENT type, the box controls which standard text value the system displays during Data Entry and DE Update. For HEADER and FOOTER types, a check identifies the default when a new DCF is created. Only one entry can be checked as default for each text type/subtype combination.

6. Write the text in the Standard Text field.

   You can embed variables in your standard text that the system replaces with values from individual records. Press F9 to see the list of values, select and insert a variable. For more information, see "Inserting Replacement Parameters" and, for examples of how the system replaces variables with actual values, Table 3-29, "Examples of Alternative Standard Text for Univariate Errors".

3.12.2 Inserting Replacement Parameters

Standard text definitions can contain standard replacement parameters, or variables. You can insert one of the replacement parameters shown in the following table into your standard text. When the system displays the standard text, it displays the actual value of the parameter. The replacement parameters are in UPPERCASE and are delimited by backslashes (\); for example, \SAS_LABEL\.

To insert a parameter in a standard text string, put your cursor in the location in the text where you want to insert the variable, press F9 or click the ellipsis (…) to display the list of values, and select it from the list of values. The following table describes each available variable and its source table or view and column.

3.12.3 Customizing Default Standard Text Entries

You can modify the default standard text in the Standard Text Maintenance form. From the Admin menu, select Discrepancy Mgmt Admin, then select Standard Text Maintenance. The window is populated with the default values for each type of univariate error message shipped with Oracle Clinical. The following table lists the default standard text definitions for Oracle Clinical.