5 Configuring Data Entry and User Preferences
This section includes:
-
Section 5.2, "Customizing the Oracle Clinical Log-in Window Layout"
-
Section 5.4, "Setting DCI Form Default Values for RDC Data Entry and Patient Data Reports"
5.1 Customizing Data Entry Behavior
A number of features, behaviors, and even the appearance of the Log-In and Data Entry screens can be configured depending on configuration settings, user preferences, and special layout editing tools. This section provides an overview of these features; more detail on each feature is available in later sections.
The features discussed in this section are:
5.1.1 Define Data Entry Configuration Settings
Data entry configuration settings, such as whether univariate validation failures alert the First-Pass and Second-Pass data entry operators, can be set at the local database level, the study level, or the user level.
Data entry configuration settings can be set at the:
-
Database Level through the Maintain Installation Configuration window; see "Configure Database-Level Data Entry Settings"
-
Study Level through the Maintain Study Configuration window (via Maintain Clinical Study States window); see "Configure Study-Level Data Entry Settings"
-
User Level through the Maintain Oracle Accounts window; see "Configure User-Level Data Entry Settings"
As the configuration level becomes more specific, from database to study to user, its settings usually take precedence over the more general level. At the local database level, each setting is either enabled or disabled. At the study and user levels, each setting is either enabled, disabled, or not set. If the value of a setting is "Not Set" it serves as a "pass-through" to the next higher level value for that setting. Initially, all values at the study- and user-level are set to "Not Set" so that the database level, which is set up during installation, is in effect until you modify the settings for a given study or user.
Study-level configuration settings affect all users who have access to that study, except when user-level configuration or Study/Site security settings are set up for a user. If a setting at this level has a value of Not Set, all users who access the study use the database-level setting, unless the value for the setting at the user level is Enabled or Disabled for a specific user.
Note:
Study-level settings of configuration parameters are not replicated during study replication. Each local database defines its own configuration settings.Note that certain privileges that are assigned via the Study and/or Site Security windows take precedence over user-level data entry configuration settings.
The settings available at each level are identical; the only difference is the availability of the "Not Set" value at the study- and user-levels. See Table 5-1, "Local Database-Level Data Entry Configuration Settings" for a complete list of settings.
5.1.1.1 Configure Database-Level Data Entry Settings
Local database configuration settings are maintained in the Maintain Installation Configuration window. You can customize the configuration settings for the local database by changing the default shipped values for the configuration settings.
At the local level, configuration settings are either enabled, disabled, or have a numeric value, as applicable. Table 5-1, "Local Database-Level Data Entry Configuration Settings" describes each setting.
-
Navigate to Admin, DE Admin, and then select DE Config Settings. The Maintain Installation Configuration window opens.
-
Navigate to the configuration setting that you want to modify, and change its value. The default page height and width settings allow numeric values within upper and lower bounds. The other settings can be set to either enabled or disabled.
-
Click Save to commit changes.
Table 5-1 Local Database-Level Data Entry Configuration Settings
5.1.1.2 Configure Study-Level Data Entry Settings
If you require that a particular study have different data entry configuration settings from those set at the local database level, you can change the settings at the study level by modifying the Clinical Study State record for that study. Study-level configuration settings override local database-level configuration settings for that study.
The study-level configuration settings are identical to the local database-level data entry configuration settings, but at the study level, an additional value, "Not Set", is available for all configuration settings. If a setting is not set, it is not defined and the next higher configuration setting takes effect. Because study-level settings take precedence over database-level, by default, all study-level configuration settings are set to "Not Set", which results in the local-level settings taking effect. See Table 5-1, "Local Database-Level Data Entry Configuration Settings" for a listing of the settings.
Values for each non-numeric setting are available from the list of values and can be either "Enabled", "Disabled", or "Not Set". The default page height and width settings allow numeric values within upper and lower bounds.
To change a study-level data entry configuration setting:
-
Navigate to Conduct, Security, and then select Clinical Study States. The Maintain Study States window opens.
-
Query for the study you want to update.
-
Open the Special menu and select DE Configs. The Maintain Study Configuration window opens.
-
Make the necessary changes to the configuration settings that you want to modify.
-
Save the changes and click Back to return to the Maintain Clinical Study States window, or click Back without saving to abandon your changes.
Changes at this level affect all users working in the study, unless user-level data entry configuration settings are defined for a user. See "Configure User-Level Data Entry Settings" for information on modifying these settings.
5.1.1.3 Configure User-Level Data Entry Settings
User-level settings affect all studies to which the user has access.
If you require that a user have different data entry configuration settings from those set at the study or the database level, you can change specific settings at the user level that supersede those higher level settings.
The user-level configuration settings are identical to the study- and database-level data entry configuration settings. As with the study level settings, an additional value of Not Set is available for all nonnumeric settings. If a setting is Not Set, the next higher configuration setting takes effect. Because user-level settings take precedence over database-level, by default they are set to Not Set, which results in the local-level settings taking effect. Table 5-1, "Local Database-Level Data Entry Configuration Settings" has a complete list of settings.
Note:
The DCI and DCM Date Required setting is inactive at the user-level.Values for each nonnumeric setting are available from the list of values and can be either Enabled, Disabled, or Not Set. The default page height and width settings allow numeric values within upper and lower bounds.
To change user-level data entry configuration settings, follow this procedure:
-
Navigate to Admin, Users, and then select Oracle Accounts. The Maintain Oracle Accounts multi-view window displays.
-
Query the user record you want to modify.
-
Open the Special menu and select DE Configs. The Maintain User Configuration window displays.
To define a user-level configuration setting, change the value of the configuration setting in this window to any value other than not set. You can change the value of a configuration setting without changing all of them.
-
Change any setting, as needed.
-
Save the changes and then click Back to return to the Maintain Oracle Accounts form, or click Back without saving to abandon your changes.
5.1.2 Configuring Additional Data Entry User Preferences
Oracle Clinical supplies a set of default values for user preferences, which are displayed in Table 5-2, "Local Data Entry User Preference Settings". These preferences remain in effect for all data entry operators unless operators override the defaults and save their own values (see Chapters 3 and 4 in Oracle Clinical Conducting a Study).
To change the default values for user preferences:
-
Navigate to Admin, DE Admin, and then select DE User Prefs. The Maintain Installation Preferences window opens.
-
Navigate to the user preference that you want to modify, and change its value. Values for each user preference are represented either as check boxes or as a list of values.
-
Click Save as Default to save the changes, and then click Exit to close the window.
Table 5-2 Local Data Entry User Preference Settings
5.1.3 Configuring Privileged Update
This section includes:
-
Set Privileged Update Using Configuration Settings—applies to Oracle Clinical and RDC
-
Set Privileged Update Using Study/Site Security—applies to Oracle Clinical only
Users with privileged update can perform the same tasks on a locked document that they can on an unlocked document. in all data entry modes: log in, first pass, second pass, update, reconciliation, and key changes.
Within RDC, enabling privileged update means that the user can take any action consistent with the study- or site-security privileges assigned to the user's name. For RDC purposes, privileged update can only be assigned through the data entry configuration settings.
In Oracle Clinical you can assign privileged update through data entry configuration settings and through study/site security.
-
If Privileged Update is not enabled for a user through the data entry configuration settings, you can use the UPD_LOCK_OC privilege to grant Privileged Update access to a user. The advantage of this approach is that you can grant the privilege for a specific site within a study, while the Data Entry Configuration settings allow specification only at the database, study, or user level.
-
If Privileged Update is enabled through the data entry configuration settings, the UPD_LOCK_OC privilege assigned through study/site security is not applicable.
5.1.3.1 Set Privileged Update Using Configuration Settings
By default, privileged update is not enabled for a user. In most circumstances, you set the Privileged Update data entry configuration setting at the user level. To do this, see "Configure User-Level Data Entry Settings".
-
To set privileged update at the study level, see "Configure Study-Level Data Entry Settings".
-
To set privileged update at the local database level, see "Configure Database-Level Data Entry Settings".
These settings apply to Oracle Clinical and RDC users.
5.1.3.2 Set Privileged Update Using Study/Site Security
For Oracle Clinical users only, when Privileged Update is not enabled for a user in the data entry configuration settings, you can grant Privilege Update access by assigning the user the UPD_LOCK_OC privilege for a particular study or site within a study.
Navigate to Admin, Users and Roles, Study Security or Site Security.
5.2 Customizing the Oracle Clinical Log-in Window Layout
Oracle Clinical data entry operators use the log-in and data entry windows to enter and display the patient data defined by Study DCMs and DCIs (see Oracle Clinical Creating a Study). (Once entered, patient data, or documents, are called received DCIs (RDCIs) and received DCMs (RDCMs).) The appearance of these windows can be modified by the log-in layout editor tool to resemble the received DCI and DCM header information that appears on the CRF. You can change the header information field prompts, change the field sequences, or even hide fields after supplying them with default values.
This section includes:
5.2.1 Using the Log-in Layout Editor
The header information in CRFs is captured in the received DCI and received DCM windows. The Log-in Layout Editor allows you to match online screens with header information on the paper CRF that you may use for source data entry.
The log-in layout editor is a different tool from the DCM layout editor. You use the log-in layout editor to match the online Log-In windows with common CRF header information. You can change the header information field prompts, change the sequence of the fields, or hide fields that have default values.
"Customizing the Oracle Clinical Log-in Window Layout" describes the log-in layout editor. Use the DCM layout editor to modify the appearance of the Data Entry windows (see "Laying out the data entry screen" in the Oracle Clinical Creating a Study).
The log-in layout editor can modify the following windows:
During log-in and data entry, the Received DCI window is the first screen that the system presents to a data entry operator. In all modes, under normal navigation, the window displayed immediately after the Received DCI window is the Smart RDCM window. This window displays underneath the Received DCI window and shows only the received DCM information required for context. To view all received DCM information, the user must navigate to the Received DCM window by invoking the function [RDCM].
To access the Log-in Layout Editor, navigate to Admin, the DE Admin, and Log-in Layout Editor. The RDCI window displays. Note the drop-down list field in the bottom-left corner of your screen. Use this window selection field to navigate between the windows. When you click on the arrow to the right of the drop-down list field, the names of all the windows are displayed. To change to another window, select it from the drop-down list. If you have changes pending when you attempt to change to another window, you are prompted to save your changes, or you can discard them.
5.2.2 Modifying the Received DCI Window
To modify the Received DCI window, select RDCI window from the drop-down list. The Received DCI window displays, showing all the received DCIs fields and their default prompts.
When you click on a field or on its prompt, the following information about the field or prompt is displayed to the right of the window selection window:
-
The prompt or field name (depending on whether you clicked on the field or on its prompt),
-
The X and Y coordinates for the field or prompt, and
-
The length of the prompt or field.
These fields are display-only and cannot be updated.
You can change the length of a prompt or of a field by clicking on the prompt or on the field and then clicking on the Increase Width or Decrease Width buttons, which increase or decrease the length of the prompt or the field.
You can change the screen position of the field and its prompt by clicking on the prompt, selecting the Move button and entering new values for the X and Y co-ordinates. The field follows the prompt. If you click on field itself, select the Move button and enter new values for the X and Y co-ordinates, it moves separately from the prompt.
You can modify the prompt text by clicking on the prompt and then editing the text.
In the RDCI window, you are limited to six lines of vertical screen space, and 80 characters of horizontal space. In the data entry form, the window will only display the height of the screen occupied by fields or their prompts. For example, if you configure the RDCI window in the log-in layout editor such that you have fields and prompts on only the first four lines, only those four lines are displayed at data entry time, leaving more room for the data entry fields.
You can hide certain fields by clicking either the prompt or the field and then selecting the Hide button. This moves the prompt and field to the Items Not Displayed section of the form. This field is not visible to the data entry operator during normal data entry functioning. The following fields must be displayed: Patient, DCI Short Name, DCI Date, DCI Time, Event, Subevent number.
To make a field displayed again, select either the prompt or the field in the Items Not Displayed section of the form, select the Display button and enter values for the new X and Y co-ordinates of the prompt or field depending on which was selected. This moves both the prompt and the field
You can make a field non-updateable by the data entry operator by double-clicking on the field. When a field has been made non-updatable, it is displayed in red in the RDCI window. You can make it updateable by double-clicking on the field again.
Save pending changes by selecting Save. To discard changes that you have made but have not yet saved, you can select Revert, which rolls back your changes to your last save. To close the form, select Exit.
To edit the layout of another window, click the arrow to the right of the Window Selection drop-down list field, and then select the window whose layout you next want to edit. If you have pending changes when you try to change windows, you are prompted to save your changes.
5.2.3 Modifying the Received DCM Window
The RDCM window is displayed to the data entry operator when the [RDCM] function is invoked.
To modify the RDCM window, select RDCM Window from the window selection drop-down list. You can modify the information that is displayed for the received DCM in the RDCM window in the same way that you modified the information in the RDCI window. All navigation and other behavior is identical. The only difference is that for RDCMs, you have twelve lines to work with vertically, rather than the six lines allotted to RDCIs. The horizontal restriction remains 80 characters for rdcms, the same as for RDCIs.
5.2.4 Modifying the Smart Received DCM Window
In all log-in and data entry modes, the Received DCI window is the first window the data entry operator sees. This window may be used to capture RDCI information in Log-In modes, or it may be used only to display RDCI information, as in the data entry modes.
Additional RDCM-level information may need to be captured, or displayed for context. For this purpose during log-in and data entry, instead of the entire RDCM window, the Smart Received DCM window is displayed underneath the Received DCI window. The Smart RDCM window contains only those RDCM fields that may require user input, or that provide minimal context for the user. In addition, page fields are displayed to indicate which RDCM of the parent RDCI is currently being displayed. Full RDCM information is available to the data entry operator by invoking the [RDCM] function.
To modify the Smart RDCM window, choose it in Window Selection drop-down list field. The Smart RDCM window is displayed.
The following fields are displayed in the Smart RDCM window:
-
Qualifying Value
-
DCM Date
-
DCM Time
-
Lab Name
Because of the unique character of the Smart RDCM window, there are limitations on the changes that you can make to the fields in this window, as follows:
-
You cannot change any characteristics of the Qualifying Value field.
-
You cannot change the position of any of the fields.
-
You cannot choose not to display one of the fields.
For Smart RDCM window fields other than the Qualifying Value, you can change only the field prompt.
After you save your changes, the next time that a data entry operator performs a log-in function in that study, the changes that you made will be visible.
5.3 Scheduling a Job to Manage Patient Updates
If any studies or study sites are using partial source data verification with a Patient SDV Plan specifying an autoselection rate and/or a number of initial patients, you must set up a recurring job to check for newly eligible patients available for patient SDV automatic selection. The job runs on all studies that use partial source data verification for patients that have become newly eligible.
To set up the schedule, select Admin, then select DE Admin, then select Schedule Pending Patient Updates Job.Depending on how often new patients become eligible for partial source data verification and the refresh rate needed by your monitors, you can program job execution frequency for an interval between every 15 minutes and daily.
The job also manages locking situations that can arise due to simultaneous requests to update the Patient Positions table. These can have the following effects:
-
When a user makes updates in the Maintain Patient Positions window, he or she may receive an error message saying that updates are pending for one or more patients in the study and to try again later. Running this job commits the updates and makes it possible to work in the Maintain Patient Positions window again.
-
When the OCL_UTILS package attempts to update a locked patient record, the update is written to the patient_positions_deferred table to be processed the next time the Pending Patient Updates job is executed.
Users can run the same job at any time from the Conduct, Security menu.
Note:
Even if you are not using patient autoselection for source data verification, you should schedule this job on a less frequent basis if you are using any ocl_utils procedure to update the patient positions table on an ongoing basis.5.4 Setting DCI Form Default Values for RDC Data Entry and Patient Data Reports
This section includes:
You set the default values for DCI Form and Graphic Layout settings for all studies in the current database in the DCI Form Local Database Settings window. These settings affect the appearance of data entry windows in RDC Onsite and the PDF output of the Patient Data Report and Blank Casebook Report in Oracle Clinical and RDC.
For each setting, you can choose to enforce the value across all studies or allow modification on the study level in the DCI Form Local Study Settings window (under Design).
By default the roles that have access to this form are RXC_USER, RXC_SUPER_NOGL, RXC_ADMIN. There is also a read-only Query version of this form (QRY Global Settings, in the same path). To query the form you must have either the RXC_SUPER or RXC_ANY role.
Access the window by navigating to Admin, then DCI Form Local Database Settings.
Settings are logically grouped, and when you open the window only the groups are displayed. To see individual settings, click the + node.
5.4.1 Setting and Enforcing Values
For each individual setting you can choose to:
-
Change the default value
-
Select the Enforce Local DB Setting check box
If you select Enforce Local DB Setting here, study designers cannot change the value at the study level in the DCI Form Local Study Settings window. If you do not select Enforce Local DB Setting here, the value is modifiable at the study level.
For more information about the DCI Form Local Study Settings window, see the Oracle Clinical Creating a Study manual.
5.4.2 Settings
This section describes the following groups of settings:
5.4.2.1 DCI Form Definition
The settings for this category are:
-
DCI Form Definition Enabled If set to Y, DCI Form definition—the use of graphic layouts—is enabled by default for all studies in the database. The study-level setting is not in the DCI Form Local Study Settings window but in Clinical Study States (under Conduct, then Security). The Easy Study Design feature does not include an explicit setting for enabling DCI Form definition; if study designers want to change the default value, they can use the Clinical Study States form.
-
GLIB DCI Forms Definition Enabled If set to Y, DCI Forms can be defined in the Global Library (under Glib, then DCMs DCIs Procedures, then DCMs or DCIs). There is no corresponding study-level setting.
5.4.2.2 DCI Form Runtime
The settings for this category are:
-
Disable Delete CRF Icon Select Y to disable the Delete CRF icon in the RDC Onsite Data Entry window. Select N to enable it. When the icon is enabled, users can click it to delete the CRF and its data.
-
Label for Customizable Patient Identifier If you are using a customizable patient identifier and you would like to display a label other than Reference (the default) in RDC Onsite, enter the label text you prefer. The label appears next to the field in the Search screen of the Home and Casebooks pages. You can use this setting only if Use customizable patient identifier? is set to Y. See the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for more information.
-
DCI Form Entry Enabled If set to Y, data entry in RDC Onsite is enabled. The study-level setting is not in the DCI Form Local Study Settings window but in the Clinical Study States window (under Conduct, then Security). The Easy Study Design feature does not include an explicit setting for enabling DCI Form definition; if study designers want to change the default value, they can use the Clinical Study States window.
-
DCI Form Field Length Restriction If set to Y, users cannot enter more characters in a field than specified by the Length attribute on the DCM Question definition for that field. If set to N and a user enters more characters than specified, the system creates a discrepancy. Overflow data that cannot be displayed on the output prints into an overflow section.
-
Display Label for DCM Question Select the source for the label of each field in the CRF; either the SAS label, the question name, or the default prompt of the corresponding question definition. The label is then used as a reference in the Discrepancies, Investigator Comments, and Audit History Navigators in the RDC Onsite data entry window.
-
Display Visit Owning Interval on MPC Page? If set to Y, the Casebooks page in RDC Onsite displays the interval—phase, period, or subperiod—to which the displayed visit belongs.
-
Enable Entry of Investigator Comments If set to Y, Investigator comments are allowed in RDC Onsite.
-
Page Labeling Compatible with Page Tracking? If set to Y, the page label in a physical page uses the same syntax as the page identification in the page tracking system. This setting applies only to studies that use Page Tracking; see Oracle Clinical Creating a Study for more information.
-
Represent Disabled Blocks as This setting applies to studies using conditional in-form branching. Select Greyed if you want conditional fields that are not expected for a patient to be displayed but grayed out. Select Hidden if you do not want such fields to be displayed at all. In this case, the next expected fields, if any, are displayed in the same area, so that there is no empty space in the middle of the page. The empty space appears at the end of the page.
-
Suppress Change Reason for new Responses If set to Y, the data entry user is not prompted for a Change Reason the first time a response is entered even if the CRF has been previously saved.
-
Suppress Change Reason Prompt for New Investigator Comment If set to Y, the Investigator is not prompted for a Change Reason the first time he or she enters a comment on a particular response.
-
Suppress Warning for Non-migrated CRFs If set to Y, the data entry user does not receive a warning when working on a CRF that was entered via another user interface—Oracle Clinical or Batch Data Load—and the CRF has not been migrated to a DCI Form version.
Note:
You cannot uncheck Enforced for this setting. There is no corresponding setting at the study level, so the value you set here is automatically enforced. -
Use customizable patient identifier? If set to Y, the system allows you to customize an additional patient identifier field for Search purposes in RDC Onsite. Values determined by your customization are stored in the Reported Reference column of the Patient Positions column in Oracle Clinical. You can change the label for the field using the Label for Customizable Patient Identifier setting. See the Oracle Clinical Remote Data Capture Onsite Administrator's Guide for more information.
5.4.2.3 General
The settings for this category are:
-
Default Unplanned Use Allowed for DCIs not in Book If set to Y, DCIs not included in a DCI Book are available for unplanned use; the default setting in the DCI Book Constraints window for the Unplanned Use Allowed if not listed below field is checked.
This setting has no effect on existing DCI Books or on DCIs already listed in the DCI Book Constraints window.
See the section on DCI Books in the Oracle Clinical Creating a Study manual for more information.
-
Layout Unit of Measurement Select the unit of measurement to be used when dimensions related to layouts are displayed. The options are: inches, centimeters, and points.
5.4.2.4 Graphic Layout Editor/Updater
This category has one setting: Enforce Length as Field Size. If set to Y, the system uses the character length defined for the question to set the minimum size of the field in the layout editor. When set to Y, if you increase the question's length in the Study DCM Questions window, the system sets the Needs Update flag to indicate the field width needs to be increased.
Note:
This setting has no effect if the DCM Question Attribute for Determining Field Width setting, which a constituent of Graphic Layout Generation - DCMS is set to DISPLAY LENGTH.5.4.2.5 Graphic Layout Generator - General
The settings in this category are:
-
Default Checkbox Check Style Select the default value for the Checkbox Style field in the startup dialog for the DCM Graphic Layout generator. which determines the symbol used in selected check boxes. The default options are: Check, Circle, Cross, and Square.
-
Default Checkbox Shape Select the default value for the Checkbox Shape field in the startup dialog for the DCM Graphic layout generator, which determines the check box shape. The options are: Circle and Square.
-
Default Checkbox Size Select the default point size for check boxes. The options are: 10, 12, 15, 20.
Note:
You can change the set of options by modifying the DCIF CHECKBOX SIZE Installation Codelist. -
Default Landscape Form Layout Template Select the default layout template that the system uses for horizontal layouts. The list of values is populated by the templates that are available in the database.
-
Default Portrait Form Layout Template Select the default layout template that the system uses for vertical layouts. The list of values is populated by the templates that are available in the database.
-
Field Font Size Select the default font point size for fields. The option are: 8, 9, 10, 11, 12, 14.
Note:
You can change the set of options by modifying the DCIF FONT TYPESIZE Installation Codelist. -
Field Font Typeface Select the default font for fields; must be a monospace font. This list is based on the DCIF Typefaces table, which is not modifiable. The list includes only Courier.
-
Prompt Font Size Select the default font point size for prompts. The option are: 8, 9, 10, 11, 12, 14.
Note:
You can change the set of options by modifying the DCIF FONT TYPESIZE Installation Codelist. -
Prompt Font Typeface Select the default font for prompts. The options are: Arial, Courier New, Symbol, and Times New Roman.
5.4.2.6 Graphic Layout Generation - DCMS
This category has one setting: DCM Question Attribute for Determining Field Width. Select the question attribute to use to determine the size of the field:
-
If set to Length, the display area accommodates the maximum number of characters allowed for the question, without scrolling. If the page is not wide enough to accommodate the field on one line, the layout generator changes it to a multi-line field.
-
If set to Display Length, the display area may not be large enough to see the full response at one time. If the page is not wide enough to accommodate the field, the layout generator will extend the field to the page margin, but will not change it to a multi-line field.
The user can scroll to view or edit the overflow of text that might occur. A Patient Data Report (PDR) that includes such a field displays the entire value in the Overflow Section of the report.
Note:
See also the Enforce Length as Field Size setting.5.4.2.7 DCI Form Generation Defaults
The settings in this category are:
-
Default Landscape Page Definition Select a default page size for horizontal pages: either US letter (OCL_USL_L) or A4 (OCL_A4_L).
-
Default Portrait Page Definition Select a default page size for vertical pages: either US letter (OCL_USL_P) or A4 (OCL_A4_P).
Note:
These settings have the same list of values, which is populated by the DCIF PAGE DEFINITION Installation Codelist. Be careful to select a landscape value for the landscape setting and a portrait value for the portrait setting.
5.4.2.8 Default Settings for Showing DCM Header Fields
This category controls the default display of DCM header field definitions.
Note that you use next category, Default DCM Header Field Prompts, to define default text for these fields' labels.
The settings for this category are:
-
Default for Show Blank Flag? If set to Y, the DCM header includes a Blank Flag field.
-
Default for Show Comment? If set to Y, the DCM header includes a Comment field, also known as the DCM Internal Comment. The DCM header data comments are available only in the Oracle Clinical Data Entry subsystem. You cannot modify the field in RDC Data Entry. Set this option to Y only to produce Patient Data Reports that show RDCM header comments entered in through Oracle Clinical Data Entry.
-
Default for Show Data Comment? If set to Y, the DCM header includes a Data Comment field. The DCM header data, which is the same as internal comments, is only available in the Oracle Clinical Data Entry subsystem. You cannot modify the field in RDC Data Entry. Set this option to Y only to produce Patient Data Reports that show RDCM header data comments entered in through Oracle Clinical Data Entry.
-
Default for Show Lab? Set to Y to enable displaying and entering the lab for an RDCM by default if the lab has any lab questions. If there are no lab questions for a DCM, Show Lab is set to N regardless of this setting.
-
Default for Show Qualifying Value? Set to Y to display the qualifying value. If there is a qualifying question for the DCM but there is no default value, Show Qualifying Value has a value of Y even if this value is set to N. If there is no qualifying question for a DCM, Show Qualifying Value has a value of N for the DCI module record regardless the value of this setting.
-
Default Visit Display Code Select the way you want the DCM header to display visit information. The options are:
-
NAME /SUB# - Visit Name, Subevent Displayed in separate fields
-
NAME+ SUB# - Visit Name, Subevent both displayed in Visit field
-
NAME ONLY - Visit Name
-
-
Hide Visit by Default? If set to Y, the DCM header does not include the visit identifier. The system sets Visit Display Code to HIDDEN by default, overriding the previous setting. Exceptions: if there is no defined clinical planned event, or the Use DCI Date setting is not selected, you cannot select value HIDDEN for the Visit Display for a DCM, and Visit Display Code defaults to the value you set for the previous setting.
5.4.2.9 Default DCM Header Field Prompts
You control the default display prompts of DCM header field definitions in this category. You control the display of these definitions in the previous category, see "Default Settings for Showing DCM Header Fields".
-
(Internal) Comment prompt Enter prompt text for an internal comment field.
-
Blank Flag prompt Enter prompt text to identify a header indicator that a DCM is blank.
-
Data Comment prompt Enter prompt text to identify a DCM header data comment field.
-
Date prompt Enter prompt text to identify a DCM header Date field.
-
Generate DCM Header Divider? If set to Y, the system generates a line between the DCM Header and the DCM.
-
Lab prompt Enter prompt text to identify a DCM header Lab identifier field.
-
Length for (Internal) Comment Prompt Enter a number to determine the maximum number of characters a comment field can hold.
Note:
This field is misnamed. It is not the length of the prompt, but the length of the comment field itself. -
Length for Data Comment Enter a number to determine the maximum number of characters a data comment field can hold.
-
Length of Visit Name Enter a number to determine the maximum number of characters a Visit Name field can hold.
-
Subevent Prompt Enter prompt text to identify a DCM subevent identifier field.
-
Time prompt Enter prompt text to identify a Time field.
-
Visit Name Prompt Enter prompt text to identify a Visit Name field.
-
Visit Name+Sub# Prompt Enter prompt text to identify the Visit Name and subevent identifier field combination.
5.4.2.10 Version Migration
If the data definitions that comprise a DCI Form change after a study has gone into production, you need to create a new layout version. These settings control whether and how to allow existing data to be migrated.
-
Allow Migration of Approved Documents? If set to Y, approved RDCIs (collected patient data) are included whenever patient RDCIs are migrated to new DCI Form versions.
-
Allow Migration of Locked Documents? If set to Y, locked RDCIs (documents) are included whenever patient RDCIs are migrated to new DCI Form versions.
-
Default Reason to Retain Approval Verification Select the default reason to supply if approvals or verifications are retained during DCI Form version migration.
You must create the available values in the APPROVE VERIFY RETAIN CODE Installation Codelist.
-
Default Reason to Reverse Approval/Verification Select the default reason to supply if approvals or verifications are reversed during DCI Form version migration.
You must create the available values in the APPROVE VERIFY REVERSE CODE Installation Codelist.
-
Default Setting for Reverse Approval Status If set to Y, DCI Form version migration changes approved RDCIs' approval status to Unapproved. If set to N, DCI Form version migration keeps approved RDCIs' approval status as Approved.
-
Default Setting for Reverse Verification Status If set to Y, DCI Form version migration changes verified RDCIs' verification status to Unverified. If set to N, DCI Form version migration keeps verified RDCIs' approval status as Verified.
-
Last Migrateable Entry Status Specify the highest status at which CRFs are included in version migration. The possible statuses are, in order from lowest to highest, with the Oracle Clinical term given first and the RDC equivalent following:
-
Received (Blank)
-
(not applicable) (Created)
-
Pass 1 Started (Entry Started)
-
Pass 1 Complete (Entry Complete)
-
Batch Loaded (not applicable)
-
Pass 2 Pending (not applicable)
-
Pass 2 Started (not applicable)
-
Pass 2 Complete (not applicable)
In addition to these statuses, the keyword ALL allows RDCIs at any status to migrate, and the keyword NONE disallows any RDCI from migrating.
-
-
User Override to Reverse Approvals? If set to Y, the user running Form Version Migration can specify whether that particular execution of Form Version Migration should reverse the status of all approved RDCIs migrated and can select a different reason for the reversal, if another option is available.
If set to N, the user running the migration cannot change the setting you selected for Default Setting for Reverse Approval Status and cannot change the default reason you set in Default Reason to Retain Approval Verification or Default Reason to Reverse Approval/Verification.
-
User Override to Reverse Verifications? If set to Y, the user running Form Version Migration can specify whether that particular execution of Form Version Migration should reverse the status of all verified RDCIs migrated and can select a different reason for the reversal, if another option is available.
If set to N, the user running the migration cannot change the setting you selected for Default Setting for Reverse Approval Status and cannot change the default reason you set in Default Reason to Retain Approval Verification or Default Reason to Reverse Approval/Verification.
5.4.2.11 Patient Data Report
The settings in this category are:
-
Bookmark Ancillary Data Section If set to Y, the system generates bookmarks for the Ancillary Data sections of the Patient Data Report (PDR).
-
Bookmark Subevents If Y, the system generates bookmarks for Visit Subevents in the PDR.
-
Bookmark Title for Ancillary Data Section Specify a title to be used for bookmarks to the ancillary data section for a CRF (if Bookmark Ancillary Data Section is set to Y). The default value is "Ancillary Data Section." In the bookmark, the system appends the word "for" followed by the bookmark label of the CRF to the value specified. Therefore with the default value the bookmark text is "Ancillary Data Section for CRF bookmark label."
-
Exclude Overflow for Hidden Protected Repeating Defaults The Patient Data report includes all default text for repeating questions in the ancillary pages. Set to Y if you do not want to include text for repeating default questions if they are hidden.
If set to Y and the CRF response field for a protected repeating default is less than one character long, the Overflow section of a Patient Data Report does not list the default values for the field. This setting provides support for a mechanism to hide certain fields in a CRF simply by restricting the field length to less than 1 character.
-
Include Approval Information If set to Y, approval information for the CRF is included in the ancillary data section. A line appears under the title of the report stating that the document was approved, who it was approved by and the date and time of approval. If the CRF is approved but has no other ancillary data, the ancillary data page is included with just the approval information.
-
Include Audit History for Fields Not Displayed in CRF This setting has effect only when Audit History is selected when the PDR is submitted. If set to Y, the audit history for CRF fields that are not displayed in the CRF is displayed at the end of the Ancillary Data Section. It is not attached to a superscript but lists all audit information for fields that are not displayed on the form—for example, if the blank flag was changed for a CRF but the blank_flag is not displayed in the form. If set to N, the audit history is not displayed for undisplayed fields.
-
Include TOC in Page Numbering If set to Y, the cover page and table of contents are counted when determining PDR page numbers. For example, if CONMED is the first domain, and the cover page and table of contents each consisted of one page, CONMED would begin on page 3 if Include TOC in Page Numbering is set to Y and on page 1 if it is set to N.
-
PDR Bookmark Data Domain Select DCI if you want Patient Data Report bookmarks to be at the DCI level, or DCM if you want bookmarks at the DCM level. See Oracle Clinical Creating a Study for information on DCIs and DCMs. Enforce Local DB Setting is checked and cannot be unchecked. The setting cannot be changed at the study level. The default value is DCI.
5.4.2.12 Validation
This category contains one setting:
Execute TMS validation during site/patient validation?
If set to Y, TMS processing is executed during site and patient validation. If a question is defined as a TMS parent question, the value is sent to TMS immediately and, if the value can be autoclassified in TMS, the derived responses are sent back. However, during patient validation TMS processing is always performed for the study as a whole, including for sites to which the current user may not have access, and the audit trail represents the changes as having been made by the user who invoked patient validation.
To avoid this, turn off TMS validation entirely in the context of patient validation by setting this parameter to N. TMS processing still occurs during batch validation.
A new setting, Execute TMS validation during site/patient validation, is available in OC under Admin->DCI Form Local Database Settings under the Validation category. This setting can be overwritten on a per study basis by going to Design->DCI Form Local Study settings.
If set to Y, TMS processing will continue to happen as part of Validate Site or Validate Patient.
If set to N, TMS will not be invoked and TMS derived questions will not be populated until the next batch validation. (Note that Validate Study in RDC invokes batch validation.) The TMS derived responses will then be created as the person running batch validation instead of the RDC user.
In RDC Onsite, you can only validate one or more patients.
5.4.2.13 Options in Group Verify dialog
The LOV of each of following settings consists of the four possible combinations of CHECKED vs. UNCHECKED and UPDATEABLE vs ENFORCE:
-
CHECKED, ENFORCED: Check box is checked and user cannot change it
-
CHECKED, UPDATEABLE: Check box is checked but user can change it
-
UNCHECKED, ENFORCED: Check box is unchecked and user cannot change it
-
UNCHECKED, UPDATEABLE: Check box is unchecked but user can change it
Exclude batch-loaded CRFs
Batch-loaded CRFs are not included in the Verify action.
Exclude CRFs with discrepancies
CRFs with one or more discrepancies are not included in the Verify action.
Exclude non-migrated CRFs
Non-migrated CRFs are not included in the Verify action.
Include CRFs for this visit only
This setting applies only if the action is invoked from the multi-patient casebook page and it applies to both the Verify and the Undo Verification dialogs.
5.4.2.14 Options in Group Approve dialog
The LOV of each of following settings consists of the four possible combinations of CHECKED vs. UNCHECKED and UPDATEABLE vs ENFORCE:
-
CHECKED, ENFORCED: Check box is checked and user cannot change it
-
CHECKED, UPDATEABLE: Check box is checked but user can change it
-
UNCHECKED, ENFORCED: Check box is unchecked and user cannot change it
-
UNCHECKED, UPDATEABLE: Check box is unchecked but user can change it
Exclude batch-loaded CRFs
Batch-loaded CRFs are not included in the Approve action.
Exclude CRFs with discrepancies
CRFs with one or more discrepancies are not included in the Approve action.
Exclude non-migrated CRFs
Non-migrated CRFs are not included in the Approve action.
Include CRFs for this visit only
This setting applies only if the action is invoked from the multi-patient casebook page and it applies to both the Verify and the Undo Verification dialogs.
Include verified CRFs only
Only verified CRFs are included in the Approve action.
Note:
Users are prevented from seeing any evidence of CRF verification status unless they are explicitly granted the BROWSE_VERIFY or other verify privilege. In order to maintain investigator ignorance of verification status, you should configure Include verified CRFs only to the UNCHECKED, ENFORCE setting. If you want investigators to see CRF verification status, grant them the BROWSE_VERIFY privilege and use the Include verified CRFs only setting as desired.5.4.2.15 Source Data Verification Plan
Use these settings to create a Source Data Verification plan for the current study. These settings can be overridden at the study site level in the SDV Site Planning tab in Remote Data Capture by a user with the necessary privileges.
Exclude batch-loaded CRFs?
When checked, indicates that even if a patient is identified as requiring 100% SDV, batch-loaded CRFs for that patient should not be presented in RDC as requiring SDV. The default is UNCHECKED.
Exclude non-migrated CRFs?
When checked, indicates that even if a patient is identified as requiring 100% SDV, CRFs for that patient that were entered via RDC Classic or Oracle Clinical and that have not been migrated to a DCI Form Version should not be presented in RDC as requiring SDV.
Initial Patients for 100%SDV
The number of initial patients to be 100% verified against original source data. Use a number between 0 and 999.
Patient auto-select rate for 100%SDV
The rate at which newly SDV-eligible patients should be tagged for SDV. For example, if the rate is 20%, every fifth patient is selected.
For more information, please refer to "Setting Up Partial Source Data Verification" in Oracle Clinical Creating a Study.
5.4.2.16 Default DCI Custom Review Requirements
The settings in this category are:
Allow CRF status change to RN when review is required?
A value of Y allows reviewers to change the CRF review status to Review not Required even when the installation setting is set to require custom reviews.
Custom Reviews are Required
A value of Y requires that all custom review types be performed for all CRFs in a Study.
5.5 Configuring Custom Review Types
To define custom review types and the privileges required to perform custom reviews in RDC, use the Installation Reference Codelist CUSTOM REVIEW TYPES.
-
For the Short Value, define the name of the privilege you will assign to users who will perform this type of review, like SAFEREV or DMREV. The short name should have 8 characters at most.
-
For the Long Value, define the name of a review type, like Safety Review or DM Review. The long value appears with review metrics in RDC summary reports and elsewhere in the RDC user interface, including the Search pane and the Assign Review Status dialog. For more information, see "Add Custom Review Types" in the Oracle Clinical Remote Data Capture Onsite Administrator's Guide.
After you activate and save these codelist values, you can assign the privileges to individual users from the Users and Roles menu under Study Security and Site Security. In RDC, users who are assigned a custom review privilege will be able to update the CRF status for the corresponding review type.
Note:
The privilege BROWSE_REVIEW allows an RDC user to view the CRF status for all review types. For more information on privileges, see "Configuring Study and Site Security Privileges" in the Oracle Clinical Remote Data Capture Onsite Administrator's Guide.5.6 Customizing Flex Fields for DCI Forms
The purpose of flex fields is to allow the CRF designer to include fields in the CRF header and/or footer that display data based on functions that you define. The input parameters to the function include data specific to the current document, such as document number and investigator ID, that let you include information based on these parameters in the document.
You add flex fields to your CRF design using the Form Layout Template (FLT) Layout Editor. The system allows you to define up to ten flex fields, any or all of which can be included in an FLT. See Oracle Clinical Creating a Study for information about the procedure to insert a flex field in a FLT.
This section describes the flex fields that are defined by default and outlines the procedure you use to customize and activate additional flex fields.
5.6.1 How Flex Fields Work
Each flex field is customized through the use of a function in the package rdcpb_client.sql. When the flex field is properly configured, it can be added to the header and/or footer, using the FLT layout editor.
The function is called by the FLT layout editor.
-
RDC Onsite runtime uses Flex Field Name (pKey) and Value (pValue).
-
The GLE uses the Flex Field Name (pKey) and Description (pDescription) parameters to populate the
At runtime, any flex fields that are in the DCI header or footer are displayed and are populated with the value returned by a call to the function that is associated with the field. By default, if there is an error in the function, the system returns NULL. No error message is provided. You can modify the program for debugging purposes so that if there is an error in the function, the system returns an error message, which it displays in the relevant flex field.
There is no separate audit history for flexfield values that change due to modifications of the underlying function call or as the result of changes to any data points upon which a function is based.
5.6.2 Flex Field Components
The functions associated with flex fields are declared in rdcps_client.sql and are written in rdcpb_client.sql. These files are copied to the $RXC_INSTALL directory during the server installation. They are executed against the database when you upgrade or install it.
The flex field functions are defined as follows:
-
Function name is of the form "FLEX_FIELDn", where n is an integer from 1 to 10, inclusive
-
Flex field name is of the form "RDCI_FLEX_FIELDn, where n is an integer from 1 to 10, inclusive, and links the flex field name to the function name.
The parameters that are available in the flex field functions are listed and described in
Table 5-3 Flex Field Function Parameters
| Parameter | Description |
|---|---|
|
pTestProd |
Describes the current mode; value is "P" if called from production mode, "T" if called from test mode. See the shipped functions for examples of usage. |
|
pRdcPopulating |
Describes if the function is called during runtime or from the layout editor. |
|
pUserId |
The Oracle account of the person logged in to the system. |
|
pUserRole |
The RDC role of the user who is logged in to the system. If the user has multiple roles, it takes the first one on the list. |
|
pStudy |
The name of the current study. |
|
pStudyId |
The ID associated with the current study. |
|
pStudyVerId |
The version of the live study. |
|
pDocNum |
The document number of the CRF. |
|
pBook |
The name of the book to which the CXRF is assigned. |
|
pBookId |
The Book ID of the book to which the CRF is assigned. |
|
pDci |
The name of the DCI for the CRF. |
|
pDciId |
The DCI ID of the DCI for the CRF. |
|
pSite |
The site of the CRF. |
|
pSiteId |
The Site ID of the site for the CRF. |
|
pInv |
The name of the investigator for the site. |
|
pInvId |
The investigator ID of the investigator for the site. |
|
pPatient |
The patient associated with the CRF. |
|
pPatientId |
The patient ID of the patient associated with the CRF. |
|
pCpeName |
The name associated with the clinical planned event (CPE) for the CRF. |
|
pCpeId |
The CPE ID of the CPE for the CRF. |
|
pSubNo |
The subevent number for the CPE. |
|
pKey |
The name of the flex field, for example, "FLEX_FIELD1". |
|
pValue |
The value that is displayed in the flex field. This is only applicable when |
|
pDescription |
The prompt that is used to designate the flex field in the |
This parameter returns "Y" if it is called from the runtime environment. It returns "N" if it is called from the layout editor. When it is set to "N", most of the other parameters are "NULL". The select statements that you use to return a flex field value should only be executed when the value of this parameter is "Y". SQL statements based on the parameters that process successfully during runtime (pRdcPopulating = 'Y') will generally fail when called from the layout editor (pRdcPopulating = 'N'). See FLEX_FIELD1 and FLEX_FIELD2 in rdcpb_clent.sql for examples of this parameter's usage.
5.6.2.1 Shipped Functions
Oracle Clinical ships with two "starter" functions and seven undefined functions:
-
FLEX_FIELD1 – Patient Initials
-
FLEX_FIELD2 – Investigator Name
-
FLEX_FIELD3 through FLEX_FIELD10 – Null
The purpose of the shipped functions is to give you an example of how to write the functions to return values based on input parameters that come from the current document. You can modify the undefined functions or the defined functions to create flex fields functions that match your particular business needs.
The functions are coded so that exceptions in the SQL statements are handled silently. This ensures that errors in flexfields do not prevent RDC data entry. For de-bugging, Oracle recommends that you use opa_trace.tableon, opa_trace.debugon, and opa_trace.debugmsg(msgstring) functions to record debug information in the opa_debug table.
The select statements used for deriving values based on the key parameters (from pStudy to pCpeName) are inside the 'IF' clause, "if pRdcPopulating='Y'". If you put the statements outside of this 'IF' clause, the function will fail when called from the layout editor when these values are null.
5.7 Customizing Online Help
Oracle Clinical provides utilities for implementing a customized version of the system's extended help (Xhelp), which is HTML-based and context-sensitive. By setting up custom help through the system, you can activate a button in Oracle Clinical's field help window that, when clicked by an end user, displays your information. The system determines the user's environment by determining the form, block, and task for the current focus. You can activate or deactivate both Oracle Clinical's help (the More button) and your own (the Custom Help button).
Oracle Clinical's help system has a three-frame HTML interface that has embedded Java script macros and XML metadata. However, the application should work with any file type that your computers recognize. You can write topic files to suit your needs and completely ignore our help system, or you can copy our system into a new directory, rewrite the topic files of your choice, and then configure calls to them.
5.7.1 Modifying Calls to Online Help Topic Files
You can create customized HTML online help files with a context sensitive call from any window in Oracle Clinical. To see your online help, users click Help and then Custom.
Create your own HTML files, put them in an accessible location, and insert the URL for the Help for each window in the OCL_DOC_INDEX table in the Developer's Toolkit.
The Oracle Clinical Help engine determines which topic file to open by comparing the user's current environment to environments listed in table OCL_DOC_INDEX. The environment is the combination of module, task, and block values. You change these calls with the Document Index form. To access this form, you must have access to the Oracle Clinical Developer's Toolkit. Navigate to Admin, then Client Doc Index. The Maintain Client DOC Index window displays. It has these fields:
-
Module Name: The code module, or form name. You can find this value in any form by navigating to Action, then Environment.
-
Task Name: A case-sensitive string that often resembles the screen name. Many forms have task names that distinguish browse mode from write mode. You can find this value in any form by navigating to Action, then Environment.
-
Block Name: A subdivision within the form. Some forms have one block. Others have many. You can find this value in any form by placing your cursor in the block and navigating to Action, then Environment.
-
Field Name: You can make calls that are context sensitive to the field level. If you leave this field blank, the system drops through to the block level. You can find this value by invoking Help and reading the value from the field window.
-
Show OC Help: This check box controls the More button. If you un-check it, you deactivate Oracle Clinical's packaged help topic for the current environment.
-
OC Document Name: This is Oracle Clinical's topic identifier. Our calls contain several parameters for invoking our help system. The Oracle Clinical Doc Name is the second half of a URL. The first half is the value of a Web Server registry variable. The help engine concatenates the two parts, invokes a new browser instance, and passes the URL to the browser.
-
Show Client Help: This check box activates the Custom button.
-
Client Document Name: This is the value you enter to create a custom call to your help topic. The Client Doc Name is the second half of a URL. The first half is the value of Web Server registry variable OPA_CUSTOM_DOC_DIR.
Note:
You must leave thecontextandtopicvalues the same as in the corresponding OC Document Name value. -
Product: The value can be AERS, RXA, RXC, RDC, or TMS.
Note:
RDC Onsite has a consistent Task Name value of RDC_HTML as well as a Product value of RDC to differentiate it from the defunct PDF version of RDC Onsite, which had a Task Name value of RDC ONSITE.To modify a call to the online help topic files:
-
Navigate to Admin and select Client Doc Index to open the Maintain Client DOC Index window.
-
Query the module, task, or block name field for the form with the help you want to modify. (This information is available by opening the form and choosing Environment in the Action menu to display the Environment window.)
-
Set the Show Oracle Clinical Help and Show Client Help check boxes as necessary for your system.
-
Enter your path/filename in the Client Document Name field, in the same row as the environment it references.
Note:
-
Calls are case sensitive. Windows Explorer may not give an accurate view of the case of a filename, or a directory name.
-
Browsers use forward slashes (/) as directory separators. If a call displays the HTML file at the end of the file, the call probably contains a backslash (\).
5.7.2 Copying Online Help Topic Files
If you copy the shipped help files to a separate directory, you can customize the content in those files, yet retain their HTML hyperlinks. You then activate your system by setting your OPA_CUSTOM_DOC_DIR registry string value to point to the duplicate directory.
5.7.3 Placing Custom Help Files
The Oracle Clinical help system provides flexibility to link to files that you create from within the online help. However, if you do create custom help files do not place them under the \html\xhelp directory. This directory may be over-written during product upgrades. Oracle suggests you create another directory under \html, for example, \html\custom_xhelp.
Note:
If you placed custom help files in the \html\xhelp\oc or the \html\xhelp\rdc directory trees in earlier versions of Oracle Clinical/RDC, you must create backups of these directories during the upgrade process.5.8 Viewing Online Help Without Oracle Clinical
In your browser, place a bookmark, or set as a favorite, the following URL:
http://computer_name.domain/code_environment/xhelp/oc/index.html
where code_environment is a string like opa52, with the last two digits corresponding to the Oracle Clinical release number.
The wwhelp.htm file provides links to all the help topics for Oracle Clinical. If you cannot find this file, contact your system administrator. Once you locate help, you can create a shortcut to the home page — or any other topic — for convenience.
Note:
If you do not have Oracle web cache set up in your environment, specify port number 7777 in the above URL.