This chapter contains the following topics:
Patient Data Reports can display clinical data as it would appear in a CRF, and can include Investigator comments, discrepancy information, and an audit history. Alternatively, you can run a report from Oracle Clinical that displays only the audit history.
This section contains the following topics:
The graphic Patient Data Report (PDR) enables you to generate reports that consist of individual or sets of documents, using criteria that you determine. You can use the PDR to print out a set of blank CRFs, which you can then fill in by hand, or you can print out an entire casebook for a particular patient.
You can run the graphic PDR in either Portrait or Landscape format. Launch the Report Submission window for your selected format: from the Conduct menu, select Conduct Reports, then select Data Validation, and choose Graphic Patient Data Report (portrait) or Graphic Patient Data Report (landscape). The format choice affects the non-CRF sections of the report only. Each CRF is presented in the format in which it was designed. This makes it possible, in the case of CRFs with landscape layouts, to have a report with the Audit History Report in portrait layout, and the CRFs in landscape.
You can also run the Audit History Report, which prints only that portion of the PDR.
In order to run reports in Oracle Clinical, your system administrator or the sponsor should provide you with the name of a report server to use when you run reports. You should ensure that this name is displayed in the Server/Queue field at the top of the Report Submission window when you initiate the process to run a report.
This section contains the following topics:
In the Patient CRF PDR that is generated in PDF mode, the Audit History, Discrepancy Data, and Deleted CRFs sections are grouped together in an Appendix.
The system provides general information about the report in the header and footer areas of certain pages in the report. Pages that reproduce a CRF display the actual CRF header and footer information.
The information that may be present in non-CRF pages includes:
The CRF number and an abbreviation of the section, with a sub-page number for multipage sections, is displayed in the upper right corner of the End Note pages.
For example, the following may be present in a header:
This indicates that the current page is the second page in the Overflow Section for the fourth CRF in the PDR.
The page number.
A cover page is generated for each Graphic PDR that Oracle Clinical produces. The purpose of the cover page is to provide information about the PDR. The components that may be included in a PDR cover page are listed and described in Table 10-1.
Table 10-1 PDR Cover Page Components
| Component | PDR Type | Description |
|---|---|---|
|
Title |
Both |
A general description of the contents of the PDR. This may be either:
|
|
Report Run by |
Patient CRF |
The name of the user who initiated the PDR. This is the full name that is associated with the user name. |
|
At |
Patient CRF |
The timestamp that the system started to run the report. |
|
Book |
Blank Workbook |
The name of the book you designated for the report. |
|
Patient |
Blank Workbook for Patient |
The name of the patient whose information is printed in the blank CRFs. Note that in Patient CRFs, this information may be included in the Report Parameters. |
|
Filter |
Patient CRF |
A listing of the search criteria when you choose Use Current Selections in the Reports window. |
|
Report Parameters |
Patient CRF |
A listing of the parameters you selected in the Report Submission window. |
|
Legend |
Patient CRF |
A display of font styles and formatting that is utilized in the current PDR. Its purpose is to provide a reference for reading data and information in the report. |
The CRF Data section is present in all graphic PDRs.
All CRF header and CRF section header information that is included in the source CRF is included in the PDR. The layout of this section is similar to the layout in the respective PDF or character CRF. The fields that are included in this section are:
| Patient (with initials) | Frozen (if the Patient is frozen) |
| Site Name | Investigator Name |
| CRF Number | Blank Flag Status (Y or N) |
| CRF Status (data entry status) | Visit Date |
| Visit Name (CPE) | Document Number |
| Entry Time | Entered By |
| Latest Modification Time | Locked Status (Y or N) |
| Discrepancy Status | Approval Status |
| Approval Time | Approver Name |
| Verification Status | Verification Time |
| Verifier | Comment Text |
If the CRF is multi-section or single-section with a CRF section header, the PDR includes a section that displays the CRF section information above each section.
| CRF Section Name | CRF Section Number (out of total, if there is more than one section) |
| Blank Flag Status (Y or N) | CRF Section Status |
| Visit Name | Visit Date |
| Visit Time (if supplied) | Entry Time |
| Lock Status (if the section is locked) | Modification Time |
| Lab (if present) | Qualifying Question (if present) |
All response data is included in the PDR. However, certain aspects of the PDR format may restrict how data values that exceed the width of the data width are presented. Refer to the "Extended Text Response Display" for further information.
The ancillary data section includes several sections.
This section appears if you request Audit History when you generate the report. It includes:
Created By: The user account that performed the first Save on the entered CRF, whether saved as Complete or Incomplete.
Role of that user
Timestamp of that CRF creation
When combined with field-level audit history, the complete history for each field can be constructed, with the caveats noted below.
For responses initially saved as null, while the CRF is in status Pass1 Started or Entry Started, the time a response changed from null to not null is not available. Once the CRF is saved Complete, field-level audit histories include an entry for the change from null to not null.
If optional DCI and DCM header fields like Comment are not entered with initial data entry, the times these fields changed from null to not null values are not available.
If a DCM is marked Blank with the initial save, and responses are subsequently entered, the times these responses were entered after the blank flag is unchecked are not available.
However, the Blank Flag history itself indicates the time the blank flag is unchecked. It can be assumed that at least one, if not all responses would have been entered at that time. Further, assuming the document is saved Complete at this time, subsequent changes of other fields from null to not null values is reported as part of the audit histories for those fields.
If the report is configured to show Approval information, the Ancillary Data page also includes the name of the individual who approved the CRF, and the date and time the CRF was approved.
End notes are used to give complete information about response data without interrupting the formatting or flow of the CRF Data Section of the PDR. The End Note section, if present, is placed immediately after the CRF Data Section.
There are four types of information that may be included in the end notes of reports that are run: investigator comments, long data values, discrepancy details and audit history. If any of the four types of ancillary data are associated with a data point, a superscript is inserted adjacent to the field. The superscripts start at "1" for each CRF and increment regularly for each field with ancillary data. In the Ancillary Data section, all end notes for a data point are grouped together under the referenced superscript.
Investigator Comments: If an Investigator comment is associated with a datapoint, the entire content of each Investigator comment is viewable.
Long Data Values: Response data values that exceed the length of the response field in the CRF PDF are displayed in their entirety in the Ancillary Data section. The exception is responses to questions of type Extended Text.; see "Extended Text Response Display".
Discrepancy Details: If an active discrepancy is associated with a response, and you have elected to include discrepancy details in your report, all such details can be viewed in the Ancillary Data section under the referenced superscript.
Audit History: If a response has been updated, and you have requested that Audit History be included in your report, the complete audit history for that field can be viewed in the Ancillary Data section under the referenced superscript. This section contains the same information as the standalone report; see "Audit History Report".
Fields defined to hold large amounts of text are shown as follows:
For extended text questions, the CRF PDF displays a prefix beginning with the word "ATTACHMENT" in uppercase and including the version number of the attachment that contains the full text of the response, then the beginning of the response text. There is no superscript.
Note:
The version number includes a subversion number following the decimal point; for example, 4.3 where 4 is the number of times a user revised the text and .3 is the number of times the system stored the text, which happens each time the user closes the Show Extended Text dialog box by clicking OK after updating text in RDC Onsite. The subversion number is used for internal auditing only.In addition, for each Extended Text question response there is a separate ancillary page labeled with the name of the CRF and the question. If the text, which can be up to 10,000 characters, does not fit on one page, the report includes additional pages as required. The Extended Text ancillary data pages are not included in the Overflow section.
If an Extended Text Question response has one audit history entry, the Extended Text Audit History page displays the full "Changed From" text. The "Changed To" value is displayed as the current data on the Extended Text ancillary page. If there are multiple audit history entries, the Changed From value is in the previous entry. Extended Text ancillary pages are the first ancillary pages displayed after the CRF data page.
This section lists all CRFs that have been deleted. If the report includes CRFs that have been deleted, they are listed in this section, which is located at the end of the PDR.
The Audit History Report is a subset of the Character PDR.
To run the Audit History Report:
From the Conduct menu, select Conduct Reports, select Data Validation, then choose the report orientation you want to use: Audit History (portrait) or Audit History (landscape).
Choose a site. The Audit History Report returns data from exactly one site.
Enter the starting patient number. This parameter is required.
(Optional) Enter an ending Patient Number. If you leave this parameter blank, the report returns the audit history of the patient in the Starting Patient field only.
(Optional) Choose a date range for which you want to examine audit history. You can choose a starting date, ending date, and qualify whether these dates represent the visit date or the date that data was first entered in the system.
(Optional) Choose an approval status for data included in the report. Approval status choices are: Approved, Not Approved, Undone (for data that was once approved but approval was removed), and Awaiting Reappr (for data that has been modified since approval). You can also choose All Statuses to include data regardless of approval status setting.
(Optional) Choose a verification status for the report data. Verification statuses include: Verified, Not Verified, Awaiting Re-Ver, and Undone. You can also choose All Statuses.
Submit the job, schedule its submission, or click Job Details.
The Verification and Approval report identifies the CRF and includes approval and verification history tables. You can execute it in both test and production modes.
Users who don't use RDC, only Oracle Clinical require the role RDC_ACCESS to execute this report.
In addition to the record types included in approval and verification histories from RDC, the Oracle Clinical Verification and Approval History report includes verification or approval records that indicate that verifications or approvals are retained during form version migration. The following table describes these two additional record types.
Table 10-2 Approval and Verification History Reports Display Events
| Operation | Comments |
|---|---|
|
Verification Retained |
The Comment field indicates that status was retained after Form Version Migration. The retain reason code is also included. The Comment is in the following format: action retained by system after form version migration. Reason RETAIN REASON CODE. Where: action is either Verification or Approval, and RETAIN REASON CODE displays the default Reason or the Reason chosen by the user. |
|
Approval Retained |
The Comment field indicates that status was retained after Form Version Migration. The retain reason code is also included. The Comment is in the following format: action retained by system after form version migration. Reason RETAIN REASON CODE. Where: action is either Verification or Approval, and RETAIN REASON CODE displays the default Reason or the Reason chosen by the user. |
To run the report, navigate in Oracle Clinical to Conduct, then Conduct Reports, Data Validation, and then select the Verification and Approval History Report. The report submission screen opens, listing the following parameters:
Table 10-3 Verification and Approval History Report Parameters
| Setting | Default Value | Required | Details |
|---|---|---|---|
|
Site to report on |
Null |
No |
The List of Values (LOV) lists all sites for the study in context. |
|
Starting patient Ending patient |
Null |
No |
LOVs for both fields. If no site is selected, all patients for the study are listed. If a site is selected, the report lists all patients for the selected site. |
|
Start date End date |
Null |
No |
There is no LOV. |
|
Type of date for starting and ending dates |
Visit |
Yes |
Visit or Creation: Choose whether the start and end dates are for the Visit date or the CRF creation date. |
|
Approval status choice |
All statuses |
Yes |
The LOV includes: All, Not Approved, Approved, Awaiting Re-Approval, and Approval Undone. |
|
Verification status choice |
All statuses |
Yes |
The LOV includes: All, Not Verified, Verified, Awaiting Re-Verification, Verification Undone. |
|
Include Approval History |
Y |
Yes |
If Y, the report includes the verification history. |
|
Include Verification History |
Y |
Yes |
If Y, the report includes the approval history. |