| Oracle® Clinical Remote Data Capture Classic Data Entry User's Guide Release 4.6.2 Part Number E18824-01 |
|
|
View PDF |
| Oracle® Clinical Remote Data Capture Classic Data Entry User's Guide Release 4.6.2 Part Number E18824-01 |
|
|
View PDF |
In Oracle Clinical and RDC Classic, the term "CRF", which is an acronym for Case Report Form, refers to the form that is used by investigators to collect information and data about a patient in the clinical trial. This form can be either paper or electronic.
In a paper-based clinical trial, a CRF is a printed document that investigators use to collect handwritten identification information and response data about a patient during the course of a visit.
In a clinical trial in which patient data is collected electronically, the CRF is represented the user interface of a computer application. In Oracle Clinical and RDC Classic, this interface is an Oracle Form with fields that you use to record data.
It is not necessary for a study to be strictly paper-based or electronic. More commonly, studies use both paper- and electronic data entry to collect patient data
Although CRF design varies based on such factors as the nature of the intervention, the type of data collected, the study protocol, or the type of clinical trial, certain aspects or components of CRFs are constant. The purpose of this section of the guide is to describe each component and discuss how to best work with it in RDC Classic.
Each CRF has an area, usually at the top of the form, in which certain identification information is collected; this includes such items as the patient's ID number, the visit date, investigator's name, site name, visit number, etc. The rest of the form is used to collect data about the patient. Usually, this area consists of a series of questions, or prompts, to which the investigator records the responses that are particular to the current patient.
This section describes the structure of CRFs and discusses how you work with CRFs in RDC Classic. Because the term "CRF" has different meanings in different contexts and for different organizations, it is important to understand what a CRF is when you work with RDC Classic. This includes the components that must be present in every CRF and those that are optional. It also includes a discussion of the statuses that RDC Classic uses to classify a CRF in various ways.
This section consists of the following topics:
Each CRF consists of questions, to which the investigator records responses for the current patient.
Usually, the protocol for a clinical study is divided into clinical planned events (CPEs). Each clinical planned event corresponds to an individual visit in RDC Classic. A visit is a discrete occurrence in time during which data about the patient (or subject) is collected. Each visit, in turn, is comprised of one or more CRFs, which are the instruments used to collect the data. Usually, a CRF will be used to collect related data, using The CRF is a discrete component that you use to collect patient data as part of a visit. In general, one copy of each CRF is assigned to each patient in the protocol.
Each CRF is comprised of one or more sections. In turn, each section is comprised of one or more questions. The purpose of the CRF is to provide a means of standardized data collection, so that the same type of data is collected for each patient in a study.
Like paper CRFs, in which similar questions are grouped together to facilitate accurate and efficient collection of data, the Data Entry window can represent CRFs with only one section and it can also display CRFs that are comprised of two or more sections. These two types of CRFs are referred to as single-section and multi-section CRFs, respectively.
No matter how many sections comprise a CRF, you view and work on one section at a time. By dividing a CRF into sections, the Data Entry window is able to present you with one group of questions at a time, which simplifies both data entry and update operations.
Each CRF section is comprised of a section header and a question area.
The CRF section header collects information about the section, such as "time since dose" or "Lab Name", in addition to the information collected in the CRF header.
A section header is required to be displayed for each section of a multi-section CRF.
When the section header is displayed, it is displayed as a tab. In multi-section CRFs, the tabs facilitate easy identification of each section and provide ready navigation between the sections (refer to Figure 16-2, "Example of a Multi-section CRF Data Entry Window").
Although a CRF may consist of more than one section, the connection between RDC Classic GUI components is always maintained: the intersection of a CRF Column and one row of the Current Patients list defines a CRF Cell; there is one CRF cell in the RDC Classic Spreadsheet associated with a single CRF, no matter how many sections comprise it; and the Data Entry Window always displays the CRF Header and only one CRF section at a time.
CRFs can be designed to collect a wide variety of patient data and information. However, certain components can be identified which are used consistently across the various types of CRFs.
RDC Classic uses CRF statuses to provide you the means to quickly assess where a given CRF is in the progression to completion. This section describes each status and explains the circumstances that cause a CRF to be assigned to it.
There are five categories of CRF status. Each category addresses a different aspect of CRF disposition in RDC Classic. The CRF icons can represent all of these statuses, however the examples used in this section show one status at a time.
This section consists of the following topics:
A CRF header contains information about the CRF itself, which allows it to be placed in the proper context and to be accurately identified. This information is crucial to the integrity of the response data that is collected in the Question Area of the CRF.
RDC Classic maintains and tracks a significant amount of information about each CRF. A portion is defined by session and study settings. This information is consistent for all CRFs associated with the patients at a given site for the current study. This includes:
Study name
Site name
Site location
Principal investigator
A portion of this information is collected automatically by context when you open the CRF. This includes:
Patient number
Visit designation
Planned or unplanned
CRF name
Other information, such as visit date, visit time, and CRF comment, must be collected manually through your input when you initiate the CRF in data entry.
The CRF header is located at the top of the Data Entry window. When you open a CRF, RDC Classic places focus in the first required field in the CRF header. You must complete all required fields in the CRF header before RDC Classic assigns the entry status "Created" to the CRF.
Refer to "Section Header" for a complete description of the CRF header.
The CRF header collects and stores information about the CRF, such as the patient name, visit number, visit date, etc. RDC Classic automatically collects a portion of this information based on the CRF cell you click to open the CRF. However, you may be required to provide certain other information that RDC Classic cannot automatically discern, for example, the date that the visit took place.
The CRF header area of the Data Entry window contains fields that collect required information about the CRF. It may also contain fields that collect optional information, for example, a Comment field.
All required fields in the CRF header must be complete before you can begin to enter response field data in the CRF question area.
Use the instructions in the following sections to complete the CRF header fields in a CRF.
The Visit Date field may or may not be present in a CRF header and, if present, can either be required or optional. If it is present, the functionality is identical in the required and optional cases. When focus is in the Visit Date field, there are several methods you can use to choose a date.
Table 2-1 Method and Description to Select Visits
| Method | Description |
|---|---|
|
Type value |
Use the current date input format to type the correct visit date in the field. (Refer to "Date Format" for information about this Preferences Window setting.) |
|
Shortcut Key |
Type
|
|
LOV |
Open the List of Values window, which displays:
|
After the correct date is displayed in the field, use either the Tab or Enter key to navigate to the next field, which is:
The next required CRF header field, if present, or
The first response field in the Question area of the first CRF section.
Alternatively, you can use the mouse to navigate to another CRF header field. This is necessary if you want to complete an optional CRF header field because RDC Classic does not automatically navigate to such fields.
To insert the comment, put focus in the Comment text field and type the message you want to include. The maximum length available for the comment is 200 characters.
You can also use the RDC Classic Field Editor to type the comment. This is particularly useful if the text of the comment exceeds the viewable portion of the field.
Select Edit, then Field Editor from the option list (or the Alt+e, e quick key combination) to open the Field Editor Window.
Like the CRF header, a section header is a consistent location for collecting general information. However, whereas the CRF Header stores information about the entire CRF, each section header stores information about the group of questions that comprise that section.
The following information may be collected in a section header:
Visit date
Visit time
CPE, the event or visit designation
A qualifying value question pair
Laboratory name
Indication that the CRF or CRF section is blank (blank flag)
The section header is optional for single-section CRFs and it is required for multi-section CRFs.
When a discrepancy is associated with a CRF section, an asterisk is displayed adjacent to the header tab label as an indication.
The question area is the central part of each CRF section because it is where the prompts and responses are collected. The question area is where you enter the majority of the information about the patient. The questions that are presented in this area are derived directly from the CRF that is currently active.
When you begin the data entry, you click an empty CRF cell in the Spreadsheet to begin to input data for a particular page of patient's visit, the data fields of the CRF header, the section header (if present), and the question area are all blank. The prompts, or questions, are displayed, each one adjacent to its associated data field.
In general, performing data entry is similar to working with online forms:
After you enter any required data in the CRF header or section header, focus automatically moves to the first data field in the question area.
You enter the appropriate response in the data field.
When you are satisfied that the data in the current field is correct, you can either:
press the Tab or Enter key, or
click in the next data field.
Continue entering data and navigating through the questions. When you complete data entry for the last question in the section and press the Tab or the Enter key, one of three actions occur:
If you are working with a multi-section CRF and the section you completed is not the last section, focus moves to the first data field in the next section.
If you are working with a single-section CRF or the last section of a multi-section CRF and the "After entry of planned CRF" checkbox is selected for CRF Progression on the Preferences Window, the CRF is saved and closed, and the next CRF in the sequence specified by the CRF Progression is opened in the Data Entry window.
If you are working with a single-section CRF or the last section of a multi-section CRF and "After entry of planned CRF" checkbox is not selected, the CRF is saved and focus remains in the last data field.
Any field in the CRF that has an ATTACHMENT prefix represents an extended text field. Note that you can enter data into extended text fields only in Oracle Clinical Remote Data Capture Onsite (RDC Onsite). For more information, refer to "View Data in Fields with an ATTACHMENT Prefix".
During data entry, you may on occasion mistakenly type the wrong value for the response to particular question. That is, there may be a certain set of "acceptable" values for a question and the response that you enter may not match any of these values because of a typographical error.
If certain criteria have been established for the responses to a question and the value you enter does not satisfy those criteria, a data entry edit check generates a discrepancy when you attempt to move from that data field. The Validation Failure Window is displayed, which notifies you that the value you entered does not meet the criteria established for the responses to that question. This gives you an opportunity to correct the data value, acknowledge the discrepancy, or explain the deviation and potentially route the discrepancy for further processing.
When you dismiss the Validation Failure window, the background color of the discrepant data field is changed from white to yellow, as an indication that it may require further action. Also, until the CRF is saved, you can return to the discrepant data field and edit the response. If you change the field to a value that is not discrepant, then the discrepancy is not saved to the database.
A simple example of this is a question that requires that the patient's gender is entered as "F" for female and "M" for male. If the study designer has configured RDC Classic to accept only these two values for this question and you attempt to input "N", an edit check will generate a discrepancy for that question.
When you complete data entry in the last field in a CRF and press the Tab or the Enter key, the system automatically saves all of the data you entered for that CRF.
At any point during data entry, you can choose to save any pending changes to the database by:
clicking the Save icon on the Toolbar
choosing File, then Save from the option list, or
pressing the F10 key.
RDC Classic is able to effectively communicate a large amount of information about your study data through the use of visual cues. The most obvious example is CRF Icons in the RDC Classic Spreadsheet, which provide you with information about the entry, discrepancy, approval, and verification statuses of every CRF currently displayed in the Spreadsheet.
The question area of Data Entry window also uses visual cues to alert you to different information associated with specific datapoints.
The background color of a response field that has a discrepancy and/or an operator comment associated with it is yellow. The text of the response is displayed in a blue font.
If both an investigator comment/discrepancy and an operator comment are associated with a response field, the background color remains yellow, but the font of the response text is red.
When you mark a CRF or CRF section blank, it signifies that you do not want to enter or save data at the present time. The blank flag gives you the option to enter data in the future, and it also signifies that the CRF or CRF section has not simply been overlooked.
Each CRF header and CRF section header may contain a blank flag. This is a check box that is clear by default. You can choose to mark a CRF or CRF section blank by selecting the blank flag that is associated with the relevant component.
RDC Classic provides a mechanism to mark an entire CRF blank. The implication and meaning of a blank CRF can vary from sponsor to sponsor, however the prerequisites and the procedure are consistent. Essentially, the CRF must be at the Created entry status and a Blank check box must be present in the CRF header.
Because this task describes the limited situation of marking a CRF blank during initial data entry, it does not address the disposition of existing data, or the manner in which individual sections in multiple section CRFs are marked blank. Rather, it describes the procedures to mark a CRF blank immediately after it is created and to mark blank a CRF that has an entry status of Created and is currently closed.
RDC Classic requires that you collect certain information before you can mark a CRF or a CRF section blank.
To mark a CRF blank, you must collect all required CRF and CRF section header fields.
To mark a CRF section blank, you must collect all required CRF header fields. In addition, you must collect any required header fields in the CRF section that you want to mark blank.
You can mark a CRF or a CRF section blank at any point during the data entry process. If the CRF or section contains data, the data is deleted, however, the system audits the data changes.
Note that all CRF header and CRF section header data, both required and optional, are unaffected by selecting and clearing the blank flag.
There is a two-way interaction between the CRF header and its constituent CRF sections when the Blank check box is selected.
When you mark a CRF blank, by selecting the CRF blank check box in the CRF header, RDC Classic automatically marks blank all CRF sections that comprise the CRF. Similarly, when you mark a CRF not blank, by clearing the CRF blank check in the CRF header, RDC Classic automatically marks not blank all CRF sections that comprise the CRF.
In contrast, when you mark a CRF section blank, the effect of the action on the rest of the CRF depends on the status of any other CRF sections:
if there are other CRF sections that are not blank, the CRF header is not affected
if the CRF section you mark blank is the last section marked blank, that is, all sections are now marked blank, RDC Classic cascades the change up and automatically marks the CRF header blank.
When you mark the CRF section not blank, the functionality is similar:
if there are other CRF sections that are marked blank, the CRF header is not affected
if the CRF section you mark not blank is the last section to be cleared, that is, all sections are now marked not blank, RDC Classic cascades the change up and automatically marks the CRF header not blank.
As a CRF progresses from creation through approval and verification to locking and freezing, RDC Classic assigns certain designations to it that describe the current state of the CRF. This section describes the four different status categories that are assigned to a CRF and defines the different status designations in each category.
There are four statuses that are assigned to a CRF. The statuses describe important aspects of the CRF that help you gauge the tasks that must be performed on a CRF. The status categories are:
RDC Classic uses a combination of color and icons to continuously display the current status of CRF. The most obvious example of these visual cues is in the RDC Classic Spreadsheet, where an icon is displayed for each CRF. The icon incorporates all of the status categories in a single CRF Cell.
Refer to "RDC Classic Spreadsheet" for a full discussion of CRF icons that are displayed in the Spreadsheet and to view examples of how RDC Classic combines different status categories in a single icon.
Tip:
When you are working in RDC Classic, you can select Help, then RDC Help Topics from the option list to quickly display the CRF Icon Legend Window, which provides a reference guide for all of the different CRF icons.In addition to the CRF icons and colors that are used in the Spreadsheet to denote CRF status, the Task Tabs also display information about the CRF in focus that is relevant to the function of the task tab. For example, the Verification displays the Verification Statuses of the currently selected CRF, the Approval displays the Approval Status of the CRF.
The entry status of a CRF describes the process of entering patient data in the CRF. Data entry proceeds from a created CRF, which is the initial stage of data entry, to the point where all data is entered and the CRF is saved.
The data entry status to which a CRF is assigned tracks its progress through the workflow. Because it tracks CRF progress, RDC Classic uses the data entry status as a trigger for certain business rules, in particular, it can control audit, approval, and verification behavior.
The data entry status is assigned at the CRF section level and, based on certain factors, the CRF takes its entry status from its constituent sections. For single-section CRFs, there is a direct correlation: the data entry status of the section is the same as that of the CRF.
The situation for multi-section CRFs is not as straightforward. There is a provision in RDC Classic that allows an entry status to be assigned to each CRF section. In the case where all CRF sections are assigned the same data entry status, the CRF is also assigned the same status. However, in the case of a multi-section CRF with individual sections at different data entry statuses, RDC Classic assigns the CRF to the earliest data entry status assigned to any section.
It is important to note that it is possible to open CRFs in RDC Classic that were originally created in Oracle Clinical.
Table 2-2 lists and describes each of the data entry status that are present in RDC Classic.
Table 2-2 RDC Classic-generated Data Entry Statuses
| Icon | Name |
|---|---|
 |
Blank - The CRF has been marked as blank. |
 |
Created - The CRF has been opened and required CRF header and Section header data has been entered and saved, but no response data has been entered. |
 |
Entry Started - Multi-section CRFs only - All required CRF header and Section header fields are completed and at least one Question area response field in one section is completed. |
 |
Entry Complete: Single-section CRFs - All required CRF header and Section header information is completed and at least one Question area response field is completed. Multi-section CRFs - All required CRF header and Section header fields are completed and at least one Question area response field in each section is completed. |
There are four entry statuses that can be generated by working in RDC Classic. These are listed and described in Table 2-2. However, RDC Classic also supports viewing and working with CRFs that are processed in Oracle Clinical. Because Oracle Clinical allows more entry status designations, RDC Classic provides information about these statuses and displays icons that reflect all of the statuses that are available in both RDC Classic and Oracle Clinical.
CRFs that are initiated in Oracle Clinical are accessible and may be updated in RDC Classic. Consequently, data entry statuses specific to Oracle Clinical are represented in the collection of CRF icons that symbolize data entry.
Oracle Clinical has the capability to use multi-pass data entry. This means that the same data is recorded in a CRF more than once, usually by different data entry personnel, in order to increase efficiency. Therefore, the entry statuses in Oracle Clinical refer "first pass" and "second pass" data entry. CRF icons that originate in Oracle Clinical may have the number "1" or "2" to designate the current data entry stage.
Table 2-3 describes the entry statuses that can be generated in Oracle Clinical.
This section discusses how a CRF progresses from 'not created' to Entry Complete.
The process of initial data entry starts with a new CRF and extends until the CRF or CRF section contains at least some response data, which is then saved to the study database. However, this process may not occur during a single session. Rather, RDC Classic permits you to open a new single-section CRF, collect the required header fields, save pending changes, and close the CRF with a data entry status of Created. At some later point, either in the same session or subsequent session, you can re-open the CRF to enter response data. This is still part of the initial data entry process. When you save the CRF with pending changes to response data, RDC Classic alters the data entry status of the CRF to Entry Complete and all subsequent changes that are made to the CRF are considered part of the data update process.
The workflow for multi-section CRFs can be somewhat different. Because RDC Classic essentially handles each section as a separate CRF, different sections can be assigned different data entry statuses. Consequently, one section in a CRF may have only section header data collected, so it is assigned the Created status and the initial data entry process is applicable to it. Another section in the same CRF may have response data collected, so it is assigned the Entry Complete status and the data update process is applies to it. The data entry status of the CRF remains at Entry Started until all CRF sections progress to Entry Complete.
Refer to "Data Review and Update" for further information about the data update process.
RDC Classic allows authorized users to lock one or more CRFs. The significance of the lock status is that, under normal circumstances, the data in the CRF cannot be updated.
Before a CRF can be locked, all pending changes in the CRF must be saved to the database. This ensures that all status changes and change reasons are captured and the audit history is complete prior to locking the CRF.
The discrepancy status of a CRF describes the presence or absence of discrepant data in the CRF and specifies if you, or someone in your user role, is responsible for taking action on it.
RDC Classic differentiates between actionable and non-actionable discrepancies to highlight and make immediately obvious those discrepancies that require your attention. This type of discrepancy is referred to as "Active." Discrepancies that require the attention of users in a role(s) other than yours are referred to as "Other." Discrepancies that have been resolved, either by the system or manually, are given the status, "Closed." Closed discrepancies do not require further attention, however, all discrepancies, once created, are tracked in the Discrepancy task tab.
The distinction between an "Active" discrepancy, that is, one that is actionable by you (or someone in your user role) and an "Other" discrepancy, one that is not actionable by you, is important in RDC Classic. It is the basis for two of the discrepancy statuses. It also means that the discrepancy status of a CRF that one user sees may be different than that which another user (in another role) sees. Of the four CRF status categories, only discrepancy status is dependent on the role of current user.
RDC Classic uses color to display the discrepancy status of a CRF in the Spreadsheet, the Discrepancy Task Tab Procedure, and relevant discrepancy windows. There are three discrepancy statuses that can be assigned to a CRF, which are listed and described in Table 2-4. Each status is rated in importance, with Active discrepancies considered more important that Other, and Other discrepancies considered more important then Closed discrepancy. This ranking takes into account a CRF that has more than one discrepancy associated with it.
The background color of a response field that has a univariate discrepancy and/or an operator comment associated with it is yellow. The text of the response is displayed in a blue font.
If both an investigator comment/univariate discrepancy and an operator comment are associated with a response field, the background color remains yellow, but the font of the response text is red.
Table 2-4 Discrepancy Statuses in RDC Classic
| Icon | Name |
|---|---|
|
None - There are no other or active discrepancies associated with the CRF. (Note that there may be closed discrepancies associated with the CRF.) |
|
Active - There is at least one actionable discrepancy in the CRF. |
 |
Other - There is at least one discrepancy that must be addressed by a user in a role other than yours. |
|
Closed - All discrepancies in the CRF have been closed and or resolved, either by the system, as the result of an update of data to non-discrepant value, or by a user. |
As stated above, the discrepancy status that is assigned to CRFs is dependent on the role of the current user. A discrepancy that is "Active" for all users in the Investigator role, may be an "Other" discrepancy for Data Managers, with the CRF discrepancy status changing accordingly.
The approval status of a CRF describes whether or not the CRF is currently approved and what has occurred, with respect to approvals, if the CRF has ever been approved. Once a CRF is approved, all changes to the approval status of the CRF are reflected in the Approval.
There are four approval statuses, which are listed, along with the corresponding CRF icon, and described in Table 2-5.
The CRF icons that represent the approval statuses are identified in Table 2-5.
Table 2-5 Approval Statuses in RDC Classic
| Icon | Name |
|---|---|
|
Not Approved - The CRF has never been approved or approval has been undone. |
 |
Approved - The CRF is currently approved. |
|
Approval Undone - The CRF was approved but a user undid the approval. |
 |
Requires Re-Approval - The CRF was updated after being approved, it must be re-approved. |
There are a limited number of events that can cause the approval status of a CRF to change. These are described in Table 2-6, "Changes in Approval Status Based on Events or User Actions".
Table 2-6 Changes in Approval Status Based on Events or User Actions
| Original Approval Status | Event or Action | Resultant Approval Status | Comment |
|---|---|---|---|
|
Not Approved |
User enters password in Password text box and user name in Windows Associated with CRF Approval |
Approved |
Undo Approval button and the approval history are displayed in the Approval task tab and the CRF icon and the task tab status line are updated. |
|
Approved |
User clicks the Undo Approval button and completes the Undo Approval Password Confirmation Window |
Approval undone |
The approval history is displayed with two records: the timestamp of initial approval, and the timestamp of the "undo approval" |
|
Approved |
Response data in the CRF is updated (modified) |
Awaiting re-approval |
The Password text box is displayed to facilitate the re-approval of the CRF and the Undo Approval button is displayed to facilitate undoing the Approval. |
|
Approval undone |
User enters password in Password text box and user name in the Windows Associated with CRF Approval |
Approved |
The status line and the approval history are updated. The Undo Approval button is displayed. |
|
Approval undone |
Response data in the CRF is updated (modified) |
Approval undone |
No change |
|
Awaiting re-approval |
User enters password in Password text box and user name in the Windows Associated with CRF Approval |
Approved |
The status line and the approval history are updated. The Undo Approval button is displayed. |
|
Awaiting re-approval |
User clicks the Undo Approval button and completes the Undo Approval Password Confirmation Window |
Approval undone |
The status line and the approval history are updated. The Password text box is displayed to facilitate approval of the CRF. |
The verification status of a CRF describes whether or not the CRF is currently verified and what has occurred, with respect to verification, if the CRF has ever been verified. Once a CRF is verified, all changes to the verification status of the CRF are reflected in the Verification.
The CRF icons that represent the verification status are identified in Table 2-7.
Table 2-7 Verification Statuses in RDC Classic
| Icon | Name |
|---|---|
|
Not Verified - The CRF has never been verified. |
 |
Verified - A user has verified the CRF. |
|
Verification undone - The CRF was verified but a user undid the verification. |
 |
Requires Re-Verification - The CRF was verified but was subsequently updated. |
There are a limited number of events that can cause the verification status of a CRF to change. These are described in Table 2-8, "Changes in Verification Status Based on Events or User Actions".
Table 2-8 Changes in Verification Status Based on Events or User Actions
| Original Approval Status | Event or Action | Resultant Approval Status | Comment |
|---|---|---|---|
|
Not verified |
User clicks the Verify button |
Verified |
The Undo Verify button is displayed in the Verification task tab. |
|
Verified |
User clicks the Undo Verify button |
Verification undone |
The verification history table is updated; the Verify button is displayed in the task tab. |
|
Verified |
Response data in the CRF is updated (modified) |
Awaiting re-verification |
The Verify button and the Undo Verify button are displayed in the task tab. |
|
Verification undone |
User clicks the Re-verify |
Verified |
The Undo Verify button is displayed in the task tab. |
|
Verification undone |
Response data in the CRF is updated (modified) |
Verification undone |
No change |
|
Awaiting re-verification |
User clicks the Verify button |
Verified |
The Undo Verify button is displayed in the task tab. |
|
Awaiting re-approval |
User clicks Undo Verify button. |
Verification undone |
The Verify button is displayed in the task tab. |
The first step in the RDC Classic workflow is termed initial data entry. It entails opening a CRF for the first time, creating it, and starting to collect CRF information and patient data. An important distinction between initial data entry and the next step in the workflow, data update, is that, while all data changes are audited throughout the workflow, once a CRF (or CRF section) is at Entry Complete status, the data update process requires that all audited data changes include a user-supplied change reason.
This section consists of the following subsections:
The sequence that a CRF follows as it progresses through the workflow depends on several criteria. Among them are:
Availability of the source data
Number of sections in the CRF
Necessity of marking one or more sections, or the entire CRF, blank
The simplest, most straightforward example of data entry occurs when all of the source data are collected and available: you can open the new CRF, enter all header data, enter all response data, and save the CRF by closing it.
However, all of the source data may not be available during initial data entry, particularly when the CRF consists of multiple sections. If you do not collect all of the data for the CRF, the minimum requirement for RDC Classic to assign the Created data entry status to CRF is that all required header fields are collected. This entails completion of required CRF header fields and, if present, CRF section header fields.
Many of the procedures in this section presume certain knowledge that is necessary to complete a task. For example, most data entry tasks assume that you can locate and open a particular CRF for a specific patient.
You may also find it helpful to review the RDC Classic QuickStart Guides, which provide concise descriptions of most tasks. These are available on the My Oracle Support Web site.
Changes to a CRF are not captured in the audit trail until the pending changes are saved to the study database. The save action, which may be implicit or explicit, cannot occur until all required header data is collected, may be triggered manually (explicitly) or by the system (implicitly). In either case, once all required header fields are collected and you save the CRF, its data entry status progresses to Created. From that point, RDC Classic audits all changes to datapoints.
All data changes that RDC Classic audits while the CRF or CRF section is in Created or Entry Started data entry status include a system-generated change reason. When the CRF progresses to the Entry Complete data entry status, the system prompts you to select a change reason for all subsequent changes.
A primary benefit of RDC Classic is the ability to transmit newly collected data across the Internet or your intranet to the study database in real-time. This transfer is initiated by the save action. During initial data entry, RDC Classic requires that certain information is collected before the system permits the CRF, and its data, to be saved to the database. However, when you collect this minimum amount of information and save it to the study database – essentially all CRF and CRF section header fields – RDC Classic promotes the CRF data entry status to Created. Similarly, when you collect at data for at least one response field and save the CRF, RDC Classic promotes the CRF or CRF section (in the case of a multi-section CRF) to Entry Complete. This progression of data entry status can serve as a check that the data you collect is added to the study database.
The following subsections discuss the prerequisites for saving a CRF during initial data entry and how focus changes when the CRF is saved, either explicitly or implicitly.
The CRF must contain certain data before RDC Classic allows you to manually save the CRF. The requirements depend on the design of the CRF.
Table 2-9 CRF Component Requirements for Manual Save
| Component | Details | Resultant Data Entry Status |
|---|---|---|
|
CRF header |
All required fields in the CRF header must contain data. |
Created |
|
CRF section header |
All required fields in each CRF section header must contain data. |
Created |
|
Response fields |
At least one datapoint in the CRF or CRF section must be collected. Mandatory response fields are not required to contain data, however, an explicit save will generate discrepancies for any uncollected mandatory fields. |
Entry Complete |
Check on the Mandatory response field row.
During initial data entry, RDC Classic interprets an explicit save to mean that you are finished working with the current CRF or CRF section.
If automatic progression is set to trigger after entry of a planned CRF, an explicit save causes the following sequence of events:
RDC Classic saves all pending changes and closes the current CRF.
It then opens the next CRF in sequence. The sequence is specified in the CRF Progression of the Preferences Window.
If automatic progression is not selected for data entry, RDC Classic saves all pending changes and places focus in the first response field of current CRF or CRF section.
During initial data entry, you have the option to mark a CRF or CRF section blank after required header information is collected.
Refer to "Blank Flag" for further information about the general process of marking a CRF or CRF section blank.
Refer to "Preferences Window" for information on changing the settings that affect data entry.
|
 Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
