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.

For more information, see:

• How Flex Fields Work
  
• Flex Field Components
  

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.

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

pRdcPopulating

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.

For more information , see:

• Shipped Functions
  

Shipped Functions

Oracle Clinical ships with two "starter" functions and seven undefined functions:

1. FLEX_FIELD1 – Patient Initials

2. FLEX_FIELD2 – Investigator Name

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