Defining Validation and Derivation Procedures

This section gives explicit instructions on how to define Validation and Derivation Procedures. It includes the following topics:

• Where to Start
  
• Procedure Definition Sequence
  
• Naming and Describing a Procedure
  
• Defining Procedure Question Groups
  
• Defining Procedure Questions
  
• Defining Correlating Questions for Procedure Question Groups
  
• Defining User Variables
  
• Defining Procedure Details
  
• Using System Variables in Pre-v3.1-Style Procedures
  
• Using Variables in V3.1-Style Procedures
  
• Adding Custom Code
  

Where to Start

You define a Procedure following one of three basic approaches:

• Creating an Entirely New Procedure
  
• Creating a New Version of a Procedure
  
• Modifying an Existing Procedure
  

Creating an Entirely New Procedure

Define a new Procedure if your company is a new Oracle Clinical user, or if you are creating a Procedure for a new DCM. See Naming and Describing a Procedure.

Always create new Procedures in the study, not the Global Library. You cannot generate or test procedures in the Global Library. To add a procedure to the Global Library, you must define and test it within a study (via the Definition subsystem), activate it, and then copy it into the Global Library.

From the Definition menu, select Validation Procedures, and then Procedures, or from Definition, choose Derivation Procedures, and Procedures.

Creating a New Version of a Procedure

Use a new version for modest changes in functionality with the option to save discrepancies created by the original version. The new version replaces the current Procedure, which is saved with a status of Retired. Select Create New Vers from the Special menu in the Procedure Definitions window.

Modifying an Existing Procedure

From either the Global Library or another study, copy, then modify, an existing Procedure that references the same or functionally equivalent Questions and DCMs. Select either Copy Proc-Study or Copy Proc-GLIB from the Special menu in the Procedure Definitions window, then modify as necessary. To view existing Procedures in detail, from the Glib menu, select DCIs DCMs Procedures, and choose Qry Validation/Derivation Procedures, or from Definition, select Validation (or Derivation) Procedures, then Procedures, then choose a study. The following restrictions apply:

• You can copy only Active Procedures.

• The Data Collection Modules, Questions Groups, and Questions referenced in the Procedure (or their functional equivalents) must exist in the study to which you copy the Procedure; otherwise the copy action is terminated with an error message.

• You can copy only Procedures with domains in the current study domain searchlist.

Procedure Definition Sequence

To define a Procedure you must perform the following tasks, the first four in the order given:

1. Naming and Describing a Procedure
2. Defining Procedure Question Groups
3. Defining Procedure Questions
4. Defining Correlating Questions for Procedure Question Groups (optional)

The following tasks have no required definition sequence, though you must define variables before you can reference them in Details:

• Defining User Variables (optional)

• Defining Procedure Details

• Using System Variables in Pre-v3.1-Style Procedures (optional)

• Using Variables in V3.1-Style Procedures

• Adding Custom Code (optional)

Naming and Describing a Procedure

To reach the Procedure Definitions window, from the Definition menu, select Validation (or Derivation) Procedures, then choose one of the options listed in the table below, according to your access privileges.

For more information, see:

• Access Privileges
  
• Defining a Procedure
  

Access Privileges

The navigation option(s) you see under Definition are determined by your access privileges. You can perform the following tasks through these menu options:

Menu Option	View and Define Procedures	Set Procedures to Active	Edit Generated PL/SQL Code
Procedures	Allowed	Allowed	Not allowed
Prov Procedures	Allowed	Not allowed	Not allowed
Procedures w Edit	Allowed	Allowed	Allowed

Defining a Procedure

To define the Procedure, enter the information requested, including:

Name

Each Procedure Name must be unique within the clinical study.

Domain

Display only. The system enters the name of the current Oracle Clinical domain.

Version

A display-only number automatically assigned to each new version of a Procedure after its creation, which is version 0. The status of a new version of a Procedure defaults to Provisional. (You can revise a Procedure in an ongoing study and save its current discrepancies by creating a new version of it—select Create New Vers from the Special menu in the Procedure Definitions window.)

Status

There are three possible statuses: Provisional (P), Active (A), and Retired (R). You can modify and test Procedures only when they are set to Provisional. See Assigning Procedure Status.

Note:

If you set an Active Procedure's status back to Provisional, all the discrepancies already created by the Procedure are hard-deleted during the next batch validation run. To avoid this, create a new version of the Procedure from the Special menu.

Sort Order

(Derivation Procedures only) Determines the order in which batch validation executes this Derivation Procedure relative to other Derivation Procedures in the same study.

Tip: If the execution order makes no difference, give the Procedure a Sort Order of 100, for example. Any number of Procedures can have the same Sort Order Number. Give a lower Sort Order Number to Procedures that generate a derived value that is used by other Validation or Derivation Procedures.

Note:

During batch validation, the system executes all Derivation Procedures before all Validation Procedures for a particular study. Validation Procedures are executed in alphabetical order by Procedure Name. Derivation Procedures are executed by Sort Order Number. If multiple Derivation Procedures have the same Sort Order Number, the system executes those Procedures in alphabetical order by Procedure Name.

Execution Context

The default setting, Off-line, is appropriate for Procedures you want to execute within the context of Oracle Clinical, either as part of batch validation or individually.

The other two settings are for use with the Remote Data Capture (RDC) option for Oracle Clinical, or with your own DCAPI application. They enable you to run a Procedure on data soon after it is entered into the system, without waiting for batch validation to run:

• On-line/DCM. Procedures with this setting are run when the RDC user saves work for a particular patient, if the Procedure's primary reference Question Group belongs to the DCM the user has just entered. Any discrepancies generated by the Procedure become visible to the user. Use this setting only if the Procedure runs on responses from only one DCM.

• On-line. Use this setting if the Procedure compares more than one DCM, or if you prefer not to have the Procedure run automatically on save in RDC.

The Validate Patient and Validate Site options in RDC's Validate menu execute both On-line and On-line/DCM Procedures for a patient or a site, respectively. For information on DCAPI implementation, see the Oracle Clinical Application Programming Interface Guide manual.

Oracle Clinical batch validation runs all Procedures, regardless of their Execution Context setting.

Note:

If you make a change to a Procedure, you must run batch validation to run the Procedure against all patients, including patients with no data changes. When On-line and On-line/DCM Procedures are executed from outside Oracle Clinical, Procedures are run only against patients with changed data, even if the Procedure itself has been modified.

Category

Choose the combination of one or multiple events (visits) and one or multiple DCMs that describes the data compared in this Procedure.

The Thes_Derivation option is for use with thesaurus DVGs. It has nothing to do with the current Thesaurus Management System (TMS).

Ver 3.1 Style?

Select the Ver 3.1 Style? box to get the best performance and functionality. See V3.1-Style and Pre-V3.1-Style Procedures.

Lab Range Dependent?

Select this box if this Procedure references a Question that is associated with a lab range. Oracle Clinical then creates lab range-related system variables for use in the Procedure. In addition, if you change the definition of a lab range and then run the Lab Procedures Re-execution Pre-Process PSUB job (under Labs), the next batch validation executes all Procedures that both

• have this box selected

• reference Questions with changed lab ranges

for all patients, even if the patients' data has not changed.

Defining Procedure Question Groups

To reach the Question Groups window, click the Q-Grps button in the Procedure Definitions window. In this window you list the DCMs and Question Groups that the Procedure will reference and define how the Procedure will process them.

For more information, see:

• Performance Issues
  
• About the Question Groups Window
  

Performance Issues

The choices you make in this window have important implications for the efficiency of the Procedures you create. This section gives tips on how to design your Procedure for optimal performance. For more detailed information, see How Procedures Work Internally.

Each cursor, or Question Group Alias, is nested inside those declared before it. So for each A record fetched, the B cursor must be opened and closed. To minimize need for cursors and maximize performance, use these design strategies:

• Use correlation whenever possible (See Correlate With, About the Question Groups Window).

  Note:

  You can correlate a Question Group only to Question Groups listed above it in the Question Groups window, so order Question Groups accordingly.

• Use qualifying expressions and Where clause extensions whenever possible in Validation Procedures. You cannot use them in Derivation Procedures. See Qualifying Expression andWhere Clause Extension.

• If you need two types of aggregate functions—for example, sum and count—from the same Question Group, use only one cursor. You can specify as many aggregates as you need using one alias for all the Questions in that Procedure Question Group.

• Use Event Range and First/Last Event Only whenever possible.

• Bear in mind the fact that the Procedure QG Cursor fetches aggregate Question Groups first, followed by the primary reference Question Group. The cursor then fetches the remaining Question Groups in the order they appear in the window, which is determined by the order in which you define them.

About the Question Groups Window

Be sure to read Performance Issues before proceeding.

In order to use a Question response value in a Validation or Derivation Procedure, you must define the Question and its DCM Question Group as part of the Procedure. In the Question Group window you can also define special processing for the Question Group.

When you include a DCM Question Group in a Procedure, you create a reference to it. A single DCM Question Group can be referenced by several Procedure Question Groups in the same Procedure. For example, to compute an average baseline value for a group of DCM Questions and compare baseline values to the latest values at each subsequent visit, you need to create two Procedure Question Groups for that DCM Question Group: one an aggregate Question Group to compute average baseline value; one to compare each subsequent value to the average baseline value.

The window includes the following fields:

Alias

A short name that uniquely identifies the Question Group and its Questions in Procedure details, correlated Question Groups, and some system variables. The name may be up to 4 characters and may not begin or end with a number. You can change this field only for Provisional Procedures. Changes automatically cascade to all uses of the alias throughout the Procedure.

Aggregate?

Select this box to use the Aggregate function to keep track of the minimum, maximum, sum, count, or average of a given Question response over all patients and visits; see Aggregate Functions. If you want to track an aggregate value for only the last n visits, do not select this box and define an aggregate lag function for the Question in the Questions window.

Primary Reference

If selected, this Procedure Question Group is the primary reference Question Group. Any discrepancies found by the Procedure are associated with this Procedure Question Group in the Discrepancy Database. If this is a Derivation Procedure, the target derived Question must be part of the primary reference Question Group. The primary reference Question Group is fetched after any aggregate Question Groups but before all others.

First in the Event Range

The first visit (clinical planned event) you want the Procedure to process.

Last in the Event Range

The final visit (clinical planned event) you want the Procedure to process.

Sort Order Event

Controls the sort order for responses to the Questions in this Procedure Question Group, based on Event and Subevent or DCM Date and Time. You must choose an ascending order you plan to enter a value in the First/Last Event Only field. Use the list of values to select the sort order type. See Sort Order.

Sort Order Extension

From the list of values, specify the innermost sort criteria for responses to the Questions in this Procedure Question Group. Default: REPEAT_SN ASC, or, where the corresponding DCM has a Qualifying Question, QUALIFYING_VALUE ASC, REPEAT_SN ASC.

First/Last Event Only

Specifies that the Procedure will process only the first or only the last event it finds for each patient.

Note:

Do not use this field in Derivation Procedures.

Single Repeat Only?

In V3.1-style Procedures, you can specify that you want to fetch only the first occurrence of a repeating Question Group.

Create Place Holder?

The Procedure creates a null DCM record when data the Procedure needs to run an expression is missing (equivalent to a SQL outer join). Since a particular Question response might be null because the data entry operator did not fill it in, rather than because the entire RDCM is missing, refine your code by referencing the Has_Data variable that Oracle Clinical creates for each Procedure Question Group with Create Place Holder? selected. Its default value is N. If data is entered for any Question in the RDCM, the system changes the value of the Has_Data variable to Y. Reference it as Alias$Has_Data.

You can use this setting to create a discrepancy if a Question response is missing, and to detect missing RDCMs.

Note:

Do not use this field in Derivation Procedures.

Correlate With

By default, Oracle Clinical fetches all data for patients with changed data, and runs each Procedure on all Question responses at all visits for the RDCM Question Group Questions specified in the Procedure definition. You can avoid unnecessary processing by setting up correlation where appropriate. See Correlation.

Note:

You cannot have both correlation and aggregation defined in the same Procedure.

To use correlation, you must specify an Alias—a Question Group with which to correlate this Question Group. The correlating alias must be displayed higher in this window than the current Question Group. You can then choose Event, Qualifying Question, or Correlating Question, or any combination of the three. See Correlation.

Where Clause Extension

A PL/SQL Where clause statement (up to 200 characters) that limits the retrieval of records for processing by the Procedure by filtering on the value of DCM key fields before each Question Group fetch. Use the List function to obtain a list of DCM key fields to use as criteria. To filter on other criteria, use the Qualifying Expression field. See Where Clause Extension.

Note:

Do not use this field in Derivation Procedures.

Qualifying Expression

A PL/SQL statement that limits the retrieval of records for processing by the Procedure. Use the List function to obtain a list of available QG Questions. You can filter on any criteria because the cursor evaluates each Question Group after the fetch. See Qualifying Expression.

Note:

• Do not use this field in Derivation Procedures.

• If you use a Question here, you must also define it as part of the Procedure by selecting Questions under Question Groups.

Custom Code

You can add code to be executed after the system fetches the Procedure Question Group you are defining by clicking the Custom Code button and entering the code. See Adding Custom Code.

Defining Procedure Questions

Reach this window by selecting Question Groups under Procedure Definition. In the Procedure Question Groups window, highlight a Question Group and click Questions.

List the DCM Questions you want to reference in the current Procedure Question Group and specify special processing, such as referencing lab ranges, as needed. When you define the Detail, or test, for the Procedure, you can use Procedure Questions' values as variables of type QUESTION using the naming convention alias.question_name.

Information on each field in the window follows:

Question Name - Use the list to define the DCM Questions that you want to reference in this Procedure Question Group.

Derived Questions that are the target of the Procedure have the following constraints:

• They must be in the primary reference Procedure Question Group.

• They cannot occur as the target of any other Detail in any other Procedure.

• You must include at least one non-derived Question in a Procedure Question Group.

Occurrence Number - Select the occurrence sequence number of the Question in the DCM Question Group. The list displays valid numbers for each available Question.

DCM Derived Question? - If the Question has been defined as a derived Question, this field is selected.

Report? - For pre-V3.1-style Procedures only. Select this box if you want this Question response included in discrepancy reports. (For V3.1-style Procedures see Using Variables in V3.1-Style Procedures.)

Aggregate Function - The Aggregate function allows you to keep track of the minimum, maximum, sum, count, or average of a given Question response over all patients and visits. (You cannot define a Question as aggregate unless its Question Group's Aggregate? box is selected in the Procedure Question Groups window.) See Aggregate Functions.

Include Lab Range? - If this Question is defined as a lab test Question, select this field. See Using Lab Ranges.

Note:

When you change a lab range (from the Labs menu, choose Labs, then Labs, then choose Ranges) you must run the Lab Procedures Re-execution Pre-Process PSUB job (under Labs). Oracle Clinical will then re-execute all Procedures that reference that changed lab range for all patients during the next batch validation.

Include Thesaurus Terms? - Select if the Question is defined as having a thesaurus DVG. The system generates up to three system variables to receive the values defined in the thesaurus DVG definition. See DVG Variables, "Thesaurus DVG Variables".

Lag Depth - Specifies the number of values of a single Procedure Question for a single patient (immediately before the current value) to make available for use in detail expressions and custom code. Oracle Clinical creates a system variable to hold each of the last n values for a Question, where n is the Lag Depth you specify. Used in aggregate lag functions and in lag checks. See Aggregate Lag Functions and Lag Checks.

Include Null in Lag? - If this field is not selected, null values are not included for lag variables, so a previous non-null value is retained until a new non-null value is available. Controls whether re-initialization occurs for each process loop, or only LAG_FLAG when the lag variable is not null. See Aggregate Lag Functions and Lag Checks.

Aggregate Lag Function? - If you want to calculate an aggregate value over only the last n values, use the aggregate lag function. See Aggregate Lag Functions.

Include Current Event in Aggregate Lag? - If selected, the aggregate lag function includes the value from the current visit. See Aggregate Lag Functions.

Defining Correlating Questions for Procedure Question Groups

To reach this window, select a Question Group in the Question Groups window that has Correlate w/ Alias? selected, and click Correlating Questions. In this window, you specify the name and occurrence number of the two Questions you are correlating. The system will run the Procedure on the response to the Question in the Question Group displayed higher in the Question Groups window only when the response value of the Question from the lower group is the same. See Correlation.

Before you can carry out the task, you must do the following:

• Select the Correlate w/ Alias? field for the current Question Group.

• Define the Questions you want to correlate in the Questions window for the current Question Group and the correlated Question Group.

Defining User Variables

To reach the User Variables window, click User Vars in the Procedure Definitions window.

User variables are variables you define and use to store values for testing and to provide temporary placeholders for generated PL/SQL code. You can use them for internal processing and/or to report values to the Discrepancy Database and in discrepancy reports. They can represent a single value or an array of values, and can be of data types character, numeric, or date/time.

You must define user variables here before you can use them in Procedure Detail expressions or custom code.

Oracle Clinical also creates system variables for use in Procedures (see Using System Variables in Pre-v3.1-Style Procedures).

Variable Name - Name of a user variable, unique within a Procedure; up to 30 characters.

Init Alias - Specify when to initialize a variable; if the field is left blank, Oracle Clinical initializes the variable for each new patient; if you specify an alias, the variable is initialized after each fetch of that alias (Question Group) cursor.

Data Type - Choose the appropriate value from the list.

Length - Specify the maximum length of the value of the variable. If you want to limit the length of a text string, or to cause number rounding, enter the limit here.

Decimal Places - Set the precision of the value of a user variable with data type NUMBER.

Initial Value - Specify the value to which the user variable is initialized. If you leave this field blank, the user variable initializes to a null value.

Report - For pre-V3.1-style Procedures only, select if you want discrepancies found on this variable to be reported. In V3.1-style Procedures you set this in the Detail Variable Settings window. See Using Variables in V3.1-Style Procedures.

Description - Description of the variable, up to 70 characters.

Defining Procedure Details

To reach the Details window, click Details in the Procedure Definitions window.

A detail is the logical test or calculation performed on data during a Procedure. It consists of a single Boolean statement that, if true, results in an entry in the Discrepancy Database. A given Procedure may contain many details, each testing a particular condition. You must define user variables before referencing them in detail expressions. See Defining User Variables and Alternative Approaches to Error Reporting.

Define a detail as follows:

• Order Number
  
• Continue If Discrepancy
  
• Test Not Null Only
  
• Detail Types
  
• Externally Derived
  
• Failure Type
  
• Description
  
• Expression
  
• Message
  
• Discrepancy Code
  

Order Number

Enter the order in which you want this detail to be executed in relation to the other details in the Procedure. You can change this number in Provisional Procedures only.

Continue If Discrepancy

Select this box if you want the Procedure to continue executing other details if this one finds a discrepancy. If so, specify the number of the detail you want to execute next in the Cont at Detail# field. (This functionality is available only in V3.1-style Procedures.)

Test Not Null Only

Select this box if you want the Procedure to execute this detail only if the Question response is not Null.

Detail Types

This field is found in the Derivation Procedure window only, since Calculation-type details are used only by Derivation Procedures to calculate derived Question responses. All other details (all details in Validation Procedures and details in Derivation Procedures that do not directly derive data) are of type Test, even if they include arithmetic functions and data manipulations. You can use Test details in a Derivation Procedure to ensure that your data is valid before you calculate the derived response, or to check the calculation after deriving it.

Externally Derived

Select this box if the response to this Question is derived by a system outside Oracle Clinical, for example, the Thesaurus Management System (TMS).

Failure Type

Specify the severity of a discrepancy generated by the Detail expression in this detail line. The failure type is associated with the discrepancy in the Discrepancy Database. You can change this field only for Provisional Procedures. Select from the list. The choices Thesaurus_PT and Thesaurus_SCT are used by the outdated Thesaurus Management Option (TMO) of Oracle Clinical; TMS does not use them. (These values are set in the installation reference codelist VALIDATION FAILURE TYPE CODE; you may want to set the TMO values to Inactive so they do not appear in this list of values.)

Note: Calculation-type details in Derivation Procedures do not generate discrepancies, and therefore, do not use this field.

Description

Free form text, up to 200 characters of mixed case, describing the Detail expression in this detail line of the Procedure. The system enters the text you enter here as the default text in the Message field. You can edit and expand it there.

Expression

In Validation Procedures and in Test-type details in Derivation Procedures, the expression is a single Boolean statement that, if true, results in a discrepancy being created. For example, in the test detail A.BP_SYSTOLIC - A.BP_DIASTOLIC < 20, the system subtracts the diastolic blood pressure from the systolic and creates a discrepancy if it is less than 20.

You can see all the variables available for use in this expression (Question, system, and user variables) by pressing F9 from this field. See Procedure Variables for further information.

In details of type Calculation in Derivation Procedures, the expression generates the derived response to a derived Question. Constraints for derivation details of type Calculation:

• You must give the Calculation Detail a lower order number than any other details that use the response.

• You can include user-entered (non-derived) Questions as input to a calculation or test detail, but not as the subject or target of the calculation detail.

• The Derivation Procedure must generate a value of the same data type as the derived Question.

Message

Free form text, up to 500 characters, that appears as a comment associated with any discrepancies this detail generates. The system enters the Description text as the default message.

Discrepancy Code

Select the code to be associated with the discrepancy in the Discrepancy Database according to your company's policy.

Using System Variables in Pre-v3.1-Style Procedures

Reach this window by the Sys Vars button in the Procedure Definitions window. In V3.1-style Procedures, this button is grayed out; you mark system variables for reporting with the Variables button in the Details window. See Using Variables in V3.1-Style Procedures.

System variables are created by the system when you create Procedure Questions that require them—for example, if you define lags as part of the Procedure, a system variable is created for each lag of the Lag Depth. View the system variables to decide whether to report related test failures as discrepancies.

Using Variables in V3.1-Style Procedures

To reach the Variables Settings window, click Variables in the Details window (not available for Calculation-type Details in Derivation Procedures or in pre-V3.1-style Procedures). You can specify the interaction of each detail and each variable as follows:

• Variable
  
• Perform Detail Only If...
  
• Discrepancy Test
  
• Report
  
• Report Order
  

Variable

The Variable field lists all variables (user, system, and Question) currently selected for the detail. You can add variables to the detail by pressing F9 and making selections from the multipick list of values. It includes all remaining variables available to the Procedure. Question variables are Questions you have selected from the Procedures menu, by selecting Question Groups, and then Questions.

Perform Detail Only If...

You can select any combination of the three fields included in this section, each of which is designed to avoid processing inappropriate data.

Not Null

If selected, Oracle Clinical will run this detail on a variable only if the variable actually contains a response value. If the variable is null (because no data was entered for the Question for a patient at a particular visit) Oracle Clinical will skip this detail.

Note that the Procedure treats the value as null if an alpha DVG value has been entered, because alpha DVG values are stored in a different field: the Exception Value Text field. Treating alpha DVG values as null is appropriate because the presence of an alpha DVG value indicates a problem with the response: either the response was missing or an alphabetical value was entered for a numeric-type field (such as TRACE for lab data). Variables can have alpha DVG values only if they are Question variables and the Question on which they are based is defined as having an alpha DVG. See Alpha DVG Subset Examples.

No Univariate Error(s)

Applicable to Question variables only. If selected, Oracle Clinical will run this detail on this variable (Question response) only if the response does not have a univariate error of the type(s) you specify in the list of values. If the response has a univariate error of the type(s) you specify, the system will skip this detail. You can choose more than one.

A univariate error is a Question response that is invalid because it does not satisfy conditions specified in the Question definition. The system creates a discrepancy for each univariate error automatically. You may not want to create additional discrepancies based on known discrepancies. The univariate error types are:

• Data Type. The response does not match the defined data type; for example, an alphabetical response for a numeric field, or an incorrect date format.

• DCM Level. Not used.

• DVG. The response entered is not included in the DVG associated with the Question.

• DVG Subset. The response entered is not included in the DVG Subset associated with the Question.

• Length. The response exceeds the length defined for the Question.

• Lowerbound. The response value is lower than the lowerbound limit defined for the Question.

• Mandatory. A mandatory response is missing.

• Upperbound. The response value is higher than the upperbound limit defined for the Question.

• Missing PT. This choice is a vestige of the Thesaurus Management Option, which is no longer supported. It has nothing to do with the current Thesaurus Management System.

• Missing SCT. This choice is a vestige of the Thesaurus Management Option, which is no longer supported. It has nothing to do with the current Thesaurus Management System.

Unresolved

If selected, Oracle Clinical will skip this detail if this variable has an irresolvable univariate error.

Discrepancy Test

If selected, Oracle Clinical will test any discrepancies found on this variable to determine whether a they are new or the same as an existing one. If the same, the system does not create a new discrepancy. This field must be selected for at least one variable in each detail. If selected, the system automatically selects Report also.

Batch validation processes only changed data, so it does not create duplicate discrepancies. Flag variables whose values you may want to compare between batch validation runs. Do not flag variables—such as Patient Name—that might trigger a discrepancy due to a simple misspelling.

Report

If selected, the value of this variable is visible in the Maintain Discrepancy Database window, associated with the discrepancy. In that window, users can choose whether or not to include the value in the Data Clarification Form as well. Be sure to report the value of the Question being tested so that, if its response value triggers the creation of a discrepancy through this Procedure, it will be possible to see the discrepant value in the Discrepancy Database window and in the Data Clarification Form. This field must be selected for at least one variable in each detail.

Report Order

If you want the variable to be reported, specify the order in which you want it to appear, in relation to other variables from this detail.

Adding Custom Code

If you need to refine Procedure tests, you can add your own PL/SQL statements of up to 4000 characters at certain points in the generated PL/SQL Procedure.

For example, use pre-details custom code to perform procedural logic prior to the detail, accumulate information for previously retrieved DCM or patient records, or retrieve information not available in the generated cursors. Or, in post-details code you can make calculations in preparation for the next cursor fetch, or maintain indexes for array variables. For more information, see Custom Code.

Oracle Clinical places your custom code in the generated PL/SQL code at the location you specify in the Custom Code Location box. See Sample Procedure Code, with Custom Code Locations for the exact location of the custom code types.

An extended list of values for variables is available by pressing F9. See Procedure Variables for information on the automatically generated variables available for you to use in custom code. See Defining User Variables for information about creating variables.

To reach the Custom Code window, click Custom Code from the Procedures Definitions window. To add custom code of type Post-QG only, you can also click Custom Code from the Question Groups window.

To add custom code you must:

1. From the Custom Code Location list, choose the place you want to put your code.
2. In the main field, enter the PL/SQL code you want to insert into the generated Procedure code at that location. Press F9 for a list of available variables. You can enter up to 4000 characters.
3. Save.
4. Repeat for each custom code location you need.
5. Generate the Procedure. From the Procedure Definition window, select Generate from the Special menu.

To view the full, generated PL/SQL code of the Procedure, go to Edit Proc in the Special menu. You must use the Procedure with Edit navigation path to reach the Procedures window. If you do not see that path, you need additional privileges to see the code.

If you have the necessary privileges, you can edit the generated code. However, if you ever generate the code again, your edits are lost. Custom code is not lost when you regenerate the Procedure.