Maintaining DCI Graphic Layouts

A DCI Graphic Layout is a graphic description of a DCI used for input in generating an HTML data entry form and PDF template for the Patient Data Report and Blank Casebook Report. This section describes how to generate and edit a DCI Graphic Layout. The Maintain DCIs window has all of the tools to create initial DCI Graphic Layouts. You can also work from the Provisional window. To open Maintain DCIs, navigate to Definition, DCIs, and DCIs. See Defining DCIs for information about maintaining DCIs.

In this section:

• Viewing DCI Graphic Layouts' Status
  
• Generating Provisional DCI Layouts
  
• Generating DCI Forms
  
• Maintaining Form Layout Versions
  
• Migrating Data to New Oracle Clinical DCI Form Versions
  

Viewing DCI Graphic Layouts' Status

The Maintain DCIs window and the DCI Modules window display the status values for a DCI's Graphic Layouts. For more information, see:

• Viewing Status Values on the Graphic Tab
  

Viewing Status Values on the Graphic Tab

Note:

The Page Tracking feature has been deprecated from Oracle Clinical release 5.4 onward. However, pre-existing studies created on earlier Oracle Clinical versions with Page Tracking already enabled will continue to function as previously configured, hence the associated documentation pertaining to this use-case has been retained as below. This content is subject to be removed in future releases.

The Maintain DCIs window has three tabs: General, Page Tracking, and DCI Layout. The parameters related to DCI Forms are on the DCI Layout tab. On this tab, you can view a summary of the status of the layouts for the DCI Form version record. You cannot change the values here. These are the values on the DCI Layout tab:

• Active Layout Version # The version number of the active layout. If the field is empty, the DCI has no active layout. This field is read-only.

• # of Retired Layouts Displays the current number of retired versions of the layout for this DCI

• PDR Page Definition Page Definition of the Provisional Layout the generator uses when it creates a Patient Data Report. The field is empty if there is no Provisional Layout.

• DCI Form Page Definition Page Definition to be used when DCI Form is generated

• Prov. Layout Version # Version number of the Provisional Layout. The field is empty if there is no Provisional Layout.

• Needs Regeneration? There is a check mark in this field if the DCI Form Layout must be generated or regenerated. This is set if the DCI Module definition has changed since the last DCI Form Layout was generated, or if there have been definitional changes to its DCM definitions.

• Needs Edit? There is a (Y) in this field if you have to edit the provisional form layout before you can generate a DCI Form. Post-edit updates can also set this flag.

• Post-Edit Layout Updates? If there have been any changes to the data definitions that comprise a DCI since the last edit, the system sets this value to Y. Conversely, if there have been no changes, this value is blank.

• Prov DCI Form Generated? If a DCI Form corresponding to the Provisional Layout has been generated, the system sets this value to Y.

Generating Provisional DCI Layouts

To generate a default Provisional DCI Graphic Layout, follow these instructions

1. Navigate to Definition, DCIs, then Provisional DCIs. Choose a study that is enabled for DCI Forms. (See Enabling DCI Forms.)
2. Select a DCI that has DCMs that are available for DCI Forms. (Set the DCMs' Available? box on the Graphic Layout tab of the Maintain DCMs window.)
3. From the Special menu, select DCI Layout, then choose Generate Provisional Layout. The Attributes for DCI Graphic Layout Generation dialog box opens. Here are the parameters you can modify:

   • Unit of Measurement: You cannot change to another measure here. (You set Unit of Measurement for the local database. Navigate to Admin, and DCI Form Local Database Settings. See the Oracle Clinical Administrator's Guide.)

   • You can choose another template. The list only displays templates that can accommodate the largest DCM block size in the DCI.

   • The PDR Page Definition is the page size for printouts of the DCI Form's Patient Data Report and viewing and printing the layout. The list of values displays the definition's name, height, width, and binding offset. The list excludes definitions where either height or width are smaller than the associated Form Layout Template's height or width dimensions, or if the binding offset would cause the form layout template to touch or overlap the edge of the Page Definition. You can change the value of the PDR Page Definition after the DCI Form is generated if necessary. See Setting Binding Offsets.

   • The DCI Form Page Definition for Page Definitions for DCI Forms. The list only includes definitions where both height and width are at least two points larger than the Form Layout Template's height and width.

   • The Checkbox Shape determines the shape for all boxes generated. You can change this value for all the DVG Questions in the group.

   • Checkbox Size: You can choose from a list of values. (You specify the list of values by populating reference codelist DCIF CHECKBOX SIZE.) You can change the size of individual boxes in the layout editor, but not the shape.

4. Click the Generate button. The system creates or overwrites the Provisional Layout for the DCI.

Generating DCI Forms

When you have a default DCI Graphic Layout, you can generate the DCI Form that will be used for RDC data entry and for the generation of Patient Data Reports. (If you want to edit the layout first, navigate to Special, Graphic Layout, and Edit Graphic Layout. See Editing Layouts for general editing instructions, or Editing DCI Graphic Layouts for DCI-specific editing instructions.) The DCI must be provisional and its DCI Graphic Layout must be valid before you can create a DCI Form.

DCI Forms are stored in the database in two formats: one in HTML to be used for data entry in RDC Onsite and another in PDF to be used for generating the Patient Data Report and Blank Casebook Report. DCI Form refers to both representations.

To generate a DCI Form:

1. From the Maintain Provisional DCIs window, select the DCI. Navigate to Special, DCI Layout, and Generate Provisional DCI Form.
2. The system prompts you for a Reports Server. If you have difficulty connecting, compare your error message to the topic descriptions in the Troubleshooting Graphic Layout Problems.
3. Click Generate. The DCI Form Generator, which resides on the Reports Server, transforms the DCI definition into both an HTML and a PDF-readable definition. The system creates a new version of the DCI Form.

   Note:

   Each CRF page must fit on a printed page or you will not be able to see all the data in the Patient Data Report. The system converts the layout separately for the PDF reports and HTML data entry. There are likely to be small differences in pixel counts. When you create a layout, test both uses.

   You can generate formatted Patient Data Reports of received data from both Oracle Clinical and RDC. From Oracle Clinical, navigate to Conduct, Conduct Reports, Data Validation, then Graphic Patient Data Report. The Blank Casebook Report can be generated only from RDC Onsite or the command line. Parameters allow you to customize the output. For information about the parameters, see the Oracle Clinical Remote Data Capture User's Guide.

Maintaining Form Layout Versions

Oracle Clinical stores your DCI Graphic Layouts and their associated DCI Form records, if any, as DCI Form Layout Versions (FLVs). You can have multiple FLVs for a DCI. You set their status in the Maintain DCI Form Versions window. The window displays the details and history of all DCI Graphic Layouts and associated DCI Form generations for a selected DCI. To access the Maintain Form Versions window, navigate to Definition, DCIs, and DCIs. Select a DCI and click the DCI Form Versions button.

For more information, see:

• Form Layout Version Rules
  
• About the DCI Form Versions Window
  
• Changing DCI Form Version Status
  
• Changing a PDR's Page Definition
  

Form Layout Version Rules

You can have multiple versions of DCI Graphic Layouts and if their associated DCI Forms. You create new versions when you want to change the layout of a DCI Form that used to collect production data. This is useful when a protocol amendment requires you to add or delete Questions. You can also make use of this capability to change to otherwise refine the layout, including changing the header and footer.

The DCI Forms Versions window is inactive if any of these criteria are true:

• The selected DCI Layout has the status Retired

• If you are in Locate DCI mode

• If you are in Query-only mode

• If DCI Form definition is not enabled for the study. (If the DCI Form Definition Enabled? box is not selected. See Configuring Local Studies.)

These rules apply when changing the status of a form layout version:

• You can change the status to Active if the DCI is Active and the DCI Form has been generated for the Provisional FLV.

• You can change the status to Provisional only if there is no production data entered against the FLV, none of the other versions have the status Provisional, and the FLV is not retired.

• You can change the status to Retired only if production data has been collected using this FLV.

• If you change an Active version to Provisional or Retired, a warning dialog box stating, "Warning: You need an active version for deriving the current version in RDC and Form Version Migration. Continue? [Yes] [No]." If you select No, the system changes the status back to the previous status.

• If you change a Retired or Provisional FLV to Active and an Active FLV exists and the above conditions do not prevent you from doing so, a dialog box states, "Changing status to Active will retire existing active form layout version. [OK] [Cancel]." If you choose OK, the system retires the Active version, and activates the current version. Otherwise no action is taken.

About the DCI Form Versions Window

This window maintains DCI Layout and DCI Form versions. For a Provisional DCI Layout, you can change DCI Layout Status, Description, Page Definitions for Printing, and DCI Form Generation. From this window you can perform all of the DCI Form activities that you can perform from the DCI window, including to generate DCI Layouts, edit or browse DCI Layouts, generate DCI Provisional Forms, and delete Provisional and Active layouts. In addition, you can copy from an existing DCI Form version record to create a new DCI Form version, you can change the PDR Page Definition, and you can specify a description for a DCI Form version. There are rules that govern these activities. The system prevents you from violating the rules. The following section describes these rules.

Changing DCI Form Version Status

A DCI Form version can have one of three statuses: P (Provisional); A (Active); or R (Retired). Across all of a DCI's versions, here are the rules about status assignment:

• Only one DCI Form version can have the Provisional status.

• Only one version can be Active.

• There can be any number of retired versions.

• You can only edit the Provisional version.

• If the DCI is Active, you can change the form version status to Active.

Each time you generate a DCI Form, the system creates a new version and gives it the next available number.

Changing a PDR's Page Definition

The system chooses the PDR Page Definition when you print the PDR Report or blank CRFs. When a PDR is printed, the individual Received DCIs are printed using the Page Definition defined for the DCI Form version associated with that RDCI. The current form version is associated with the RDCI at the time of data collection and can be changed by migrating data. Migrating data is covered in the next section.

Migrating Data to New Oracle Clinical DCI Form Versions

You can control the migration of patients to a specific DCI Form version of a DCI by assigning the patients to DCI Books. The DCI Books specify the preferred version for its DCIs through the DCI Book Constraints window. (For more information on version constraints and setting preferred versions, see Defining DCI Book Constraints. You control the migration by assigning only the patients you want to migrate to a modified book. The preferred version of the DCI Book also controls the version of the form to be used for data entry in a new CRF. See Running Form Version Migration for instructions on executing the migration.

In this section:

• Assigning Patients for Migration
  
• Form Migration Examples
  
• Maintaining Approvals and Verifications During Form Version Migration
  
• Configuring Default Settings
  
• Running Form Version Migration
  

Assigning Patients for Migration

A DCI's preferred version setting in its DCI Book constraints specifies the target version for the migration. By assigning only specific patients to the DCI Book that is being migrated, you can control what patients are migrated to what version. It is possible to set up different DCI Books to point to different versions so that some patients are migrated to one version while other patients assigned to a different DCI Book are migrated to different versions. This is particularly useful for controlling migration on a site-by-site basis.

Migration and assignment of a DCI Book to a patient must occur at the location that owns the patient. However, the generation and creation of DCI Form versions, creating DCI Books, and defining DCI Book constraints occurs at the study owning location. Version migration is a cooperative effort between sponsor and site.

There are two ways to assign a patient to a DCI Book:

• You can automatically assign patients to a DCI Book when data is entered using a DCI Book, depending on how the BOOK_USAGE and the OCL_STATE reference codelists are configured.

• Patients can be initially assigned or changed to a book through the Maintain Patient Positions window.

Depending on the study migration settings, all or some of the received data assigned to the DCI Book migrates, even though the data was entered against other DCI Books.

Form Migration Examples

The following are examples of some of the possibilities available with version migration.

Example 12-1 Adding a Question to a DCI Form and Selectively Rolling Out the Change

You decide to add a Question named PREGNANCY to a DCM named AE and remove Question SMOKING. The AE DCM is used in several DCIs and DCI Books. There is already RDC received data entered via DCI Forms. No patients are assigned to a DCI Book. You want to roll this out for new entry to all locations, but you want to migrate existing data only at the current location. Because data has already been collected, you need to create a new DCI Form version. Here are the steps:

1. From the DCMs window, navigate to the DCM Questions window.

2. Mark the SMOKING Question as not collected in subset.

3. Add the PREGNANCY Question to the DCM.

   Edit the Graphic Layout to include the new Question to the DCM.

4. Edit the Graphic Layout to include the PREGNANCY Question.Set Available to Y on the Graphic Layout tab.

5. For each DCI that uses the DCM where you want to incorporate Question PREGNANCY, if you want to incorporate the new Question:

   1. If no Provisional Form Version exists, either (1) generate a new Provisional Form layout or (2) copy an existing form version to serve as a basis for the new Provisional Form Version.

   2. Edit the existing Provisional Form layout or the one created by the previous step. This will automatically incorporate the new Question.

   3. Verify you want to use the new layout.

   4. Generate the DCI Form version.

   5. Make the DCI Form version active. No changes should be needed for the DCI Book Constraints: by default, the preferred version for the DCI Book Constraint is CURRENT.

6. Assign the patients to a DCI Book that includes the relevant DCI. There must be a DCI Book Constraint record for the DCI. If it is an unplanned DCI, Unplanned Use Allowed must be checked.

7. Migrate data for the specified DCI Book. (See Running Form Version Migration.)

Example 12-2 Changing a Header

You decide to add a logo, include Investigator, and reposition existing fields in the header of an existing DCI Form for which there is received data. All patients are assigned to the same DCI Book that includes the DCI. A DCI Book constraint specifies the CURRENT version for the DCI. All data has been collected through a DCI Form.

To create a new DCI Form version and migrate the data:

1. Modify or create a Form Layout Template to incorporate the changes.

2. Generate a new Provisional Form Layout Version for the DCI. If you created a new Form Layout Template, specify the new Form Layout Template.

3. Generate the DCI Form version.

Maintaining Approvals and Verifications During Form Version Migration

The Form Version Migration window has controls to retain or reverse approvals or verifications for CRFs that are being migrated to a new form version. Before the patch, form version migration reversed all approvals and verifications. With the new controls on the Form Version Migration window, you can indicate whether a form version migration warrants either re-approving or re-verifying, the affected CRFs.

You can also set default settings at the database and study levels.

Setting Up the Reference Codelists

There are two reference codelists that provide the set of possible Reasons for retaining or reversing approvals and verifications. APPROVE VERIFY RETAIN CODE populates a list of reasons for retaining a book's approvals and verifications, and APPROVE VERIFY REVERSE CODE populates a list of reasons for reversing a book's approvals and verifications.

You can provide a single, generic reason for each codelist, as described in the following section. Or, you can use these codelists to characterize the types of form changes that do and do not require reversal of verifications and approvals. For example, perhaps a new label for a field requires re-approval, but the addition of a field does not.

In the Form Version Migration window, if the user applies the same action (Retain or Reverse), to both Verifications and Approvals, then Oracle Clinical populates the same reason to both Verifications and Approvals. The user can change either reason.

Setting Up Codelist APPROVE VERIFY RETAIN CODE

To modify the list of reasons for retaining a book's approvals and verifications:

1. In Oracle Clinical, select Admin, then Installation Codelists.

2. Query APPROVE VERIFY RETAIN CODE in the Name field. The upgrade includes one entry:

   • Short Name: DFLT_RETAIN_R You cannot change this value.

   • Long Value: The default text is: (Sample) Form update does not warrant reversal. You can change this text.

   • Description: You can add a description in this field.

3. Add more entries. Both the Short and Long values appear in the list of values displayed in the Form Version Migration window.

Setting Up Codelist APPROVE VERIFY REVERSE CODE

To modify the list of reasons for reversing a book's approvals and verifications:

1. Query APPROVE VERIFY REVERSE CODE in the Name field. The upgrade includes one entry:

   • Short Name: DFLT_REVERSE_R You cannot change this value.

   • Long Value: The default text is: (Sample) Form update requires reversal. You can change this text.

   • Description: You can add a description in this field.

2. Add more entries. Both the Short and Long values appear in the list of values displayed in the Form Version Migration window.

Configuring Default Settings

This section describes configuring approval and verification retention options at the database and study level.

Configuring Default Settings at the Database Level

If you have Superuser or Administrator privileges, you can set the default Retention or Reversal policy for approvals and verifications at the database level:

1. In Oracle Clinical, select Admin, then DCI Form Local Database Settings. Then click on the Version Migration plus symbol. The Version Migration category includes the following new settings:

   • Default reason to retain approval/verification Choose an entry from the list of values. The list of values draws from the APPROVE VERIFY RETAIN CODE reference codelist.

   • Default reason to reverse approval/verification Choose an entry from the list of values. The list of values draws from the APPROVE VERIFY REVERSE CODE reference codelist.

   • Default setting for Reverse Approval Status Select Y or N.

   • Default setting for Reverse Verification Status Select Y or N.

   • Last Migrateable Entry Status Choose the data entry mode from the list of values Choose a data entry status from the list of values.

   • User Override to Reverse Approvals? Select Y or N. If you choose Y, the user executing the form version migration can change the default reversal or retention policy for approvals.

   • User Override to Reverse Verifications? Select Y or N. If you choose Y, the user executing the form version migration can change the default reversal or retention policy for verifications.

2. Save.

Configuring Approval and Verification Settings at the Study Level

You can enable or disable approvals and verifications at the study level:

1. In Oracle Clinical, select Design, then DCI Form Local Study Settings. Then click on the Version Migration plus symbol. The Version Migration category includes the following new settings:

   • Default reason to reverse approval/verification Choose an entry from the list of values. The list of values draws from the APPROVE VERIFY REVERSE CODE reference codelist.

   • Default reason to reverse approval/verification Choose an entry from the list of values. The list of values draws from the APPROVE VERIFY REVERSE CODE reference codelists.

   • Default setting for Reverse Approval Select Y or N.

   • Default setting for Reverse Verification Status Select Y or N.

   • Last Migrateable Entry Status Choose the data entry mode from the list of values Choose a data entry status from the list of values.

   • User Override to Reverse Approvals? Select Y or N.

   • User Override to Reverse Verifications? Select Y or N.

2. Save.

Running Form Version Migration

In Form Version Migration window you can retain or reverse Approvals and Verifications in the existing DCI book response data.

• Migration occurs for all patients assigned to the selected DCI Book.

• Migration occurs for all patients assigned to the selected DCI Book, and all CRFs entered using a DCI where the (new) form version is later than the version used for the initial data entry.

The following graphic shows the new controls for verifications and approvals in the Form Version Migration window:

Description of the illustration mfv_form.gif

To run a form version migration:

1. In Oracle Clinical, select Definition, then DCIs, and finally, Migrate Form Version by Book. The Migrate Forms Version by Book window opens.
2. If necessary, you can change the study by clicking the Change Study button.
3. Select the DCI Book from the DCI Book Name list of values.
4. If available, choose to retain or reverse Approvals in the DCI Book, and choose a reason from the list of values. If you cannot override the default settings, you are prevented at the database or study levels.
5. If available, choose to retain or reverse Verifications in the DCI Book, and choose a reason from the list of values. If you cannot override the default settings, you are prevented at the database or study levels.

   Note:

   If you choose to retain both Approvals and Verifications, upon choosing a reason in either field, Oracle Clinical automatically chooses the same reason in the other field. You can change the reason to another choice, if necessary. The same happens for reversals: If you choose to reverse both Approvals and Verifications, upon choosing a reason in either field, Oracle Clinical automatically chooses the same reason in the other Reason field. You can change the reason to another choice, if necessary. If you choose to retain Approvals but reverse Verifications, or vice versa, then you must choose a reason for both approvals and verifications.

6. Select Test Run to perform a test run of the migration. Oracle Clinical returns the number of RDCIs eligible for migration. It does not commit the form migration to the database. To execute the Form Version Migration, unselect Test Run.
7. Click Submit Job to queue the migration job.
8. You can click the Job Status button to check on the job's progress.