| 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 |
Oracle Clinical is a clinical data management system that provides a full suite of capabilities that facilitate study design, development of validation procedures, data entry, replication, discrepancy management, and handling of laboratory data. In Oracle Clinical, data entry activities generally occur at the sponsor site via workstation computers that are linked directly to the hardware on which the Oracle Clinical application reside.
Remote Data Capture Classic (RDC Classic) is an electronic data capture (EDC) application that is tightly integrated with Oracle Clinical and allows you to move data entry activities investigator sites, where you collect and work with patient data. When you record the data in RDC Classic and save it to the Oracle Clinical database, it is immediately available to all other users, as well as to any procedures and post-processing activities that are set up to ensure clean data. Using RDC Classic, you also have the capability to view and work with data that was collected either through Oracle Clinical or other investigator sites using RDC Classic.
The following sections describe topics that are fundamental to working with Oracle Clinical RDC Classic:
A primary goal of a clinical study is to collect high quality data. The combination of Oracle Clinical and RDC Classic allows users to improve the quality of the data by providing a mechanism to record patient data at the location where it is collected. This section provides an overview of EDC, discusses how RDC Classic accomplishes EDC, and describes how RDC Classic interacts with Oracle Clinical.
EDC allows you to perform data entry, verification, approval, and data management at the investigative site, that is, remotely, using a network to communicate with study database, which is usually located at a sponsor facility. RDC Classic provides this capability with the added assurance that all updates to patient data are saved immediately to a single, centralized database that is managed by database administrators (DBAs).
RDC Classic provides real-time access to and interaction with the database where the clinical data for a study is collected, as well as communication with other study workers. By utilizing secure, online access across the Internet (or an Intranet), RDC Classic facilitates immediate transfer of all data changes to the database and it provides direct feedback, in the form of queries or discrepancies, about patient data and related information, which allows such issues to be dealt with in a timely manner.
Because you have access to the study database from within your RDC Classic session, you can use RDC Classic to run reports for any set of patient data that has thus far been collected (subject to the privileges assigned to your user name). You can also use the RDC Classic report feature to generate reports comprised of all CRFs in a casebook, with or without patient information in the header areas.
The model for gathering, collating, resolving, and managing clinical trial data has been to send paper Case Report Forms (CRFs) from study sites to a central location. The data contained in the paper CRFs was then manually transferred to the study's database by data entry operators. Any questions about the information contained in a CRF, such as those arising from typographical errors or ambiguous values, had to be routed through a data manager and resulted in a letter being sent to the study site, via postal mail or fax. At the study site, the investigator had to research the problem from medical charts that may have been completed months before, come to a conclusion, draft a response to the query, and send it back, again via postal mail. The entire process may have taken months to complete for a small set of questionable data. This delay is a cause of the lengthy amount of time that clinical trials took to complete. It also resulted in significant data management hurdles.
Oracle Clinical and RDC Classic solve the problems related to time delays and miscommunication by allowing direct access between users at clinical sites and the Oracle Clinical system. This allows users to complete tasks at investigator sites that previously were done via the post or directly at the location where the study database computer resided. It also facilitates direct communication, within the application, between sponsor and site personnel, which enhances accuracy and streamlines the entire data entry process.
RDC Classic is designed to run on the computer in your office. The primary requirements are a connection to the Internet or an intranet, several basic software applications, and several RDC Classic -specific add-ons to those applications. (Refer to "System Requirements" for more information.)
When you launch RDC Classic and initiate a session, the application connects to a computer at the study sponsor's location. The two computers communicate with each other and you are given access to existing patient information and data that is relevant to your assigned role in the study. Among the tasks you can complete, with the appropriate security settings, from within your RDC Classic session are:
Add new data
Edit existing data
Assign patients to the study
Identify, initiate, and resolve discrepancies
Verify CRFs
Approve CRFs
Lock and unlock CRFs
Run reports
RDC Classic connects via the Internet to an Oracle Clinical installation on the sponsor's computer, which is usually at a different location. Data that you update in RDC Classic is immediately saved to the study database. Using RDC Classic, you can access data that was collected in Oracle Clinical. Similarly, Oracle Clinical users can access data that you collect in RDC Classic.
This section describes the hardware and software that you need to run RDC Classic. It includes the following topics:
While most of the software you need to work in RDC Classic resides on the computer at the sponsor site, there are several requirements that your computer must meet in order to properly initiate and run an RDC Classic session.
The following sections detail the system requirements for all computers you use to run RDC Classic:
This section describes the hardware requirements for running RDC Classic on end user computers.
The type of network connection you have determines, to a great extent, how quickly RDC Classic is able to communicate with the study host's computer. RDC Classic can operate over any local area network, intranet, or internet connection, including dial-up. For details, refer to the release notes that accompanies this version of RDC Classic release.
Oracle certifies the software described in this section to be necessary or suitable for running RDC Classic.
Note:
To view, print, and/or save patient data reports Adobe Acrobat or Reader 5.1 or 6.0 must be installed on your computer.RDC Classic is certified to run on computers with the following operating systems:
Microsoft Windows 2000, Service Pack 4
Windows XP, Service Pack 2
This section lists the configuration settings for the applications that RDC Classic uses.
Note:
In order to ensure the functionality of the Date Selection Window, Microsoft's ActiveX Calendar Control file (mscal.ocx) must be installed on your computer. Refer to Microsoft documentation if you have difficulty with the Data Selection window.Ensure that Microsoft Internet Explorer, version 6, is configured according to the following sections.
Microsoft Internet Explorer must be designated as the default browser on your computer. To ensure this:
Open Microsoft Internet Explorer 6.
Select Tools, then Internet Options menu command.
Select the Programs tab.
Select the check box for the Internet Explorer should check to see whether it is the default browser setting.
When you next access an Internet browser, if the system displays a message window that states Internet Explorer is not the default browser, select the check box that sets it as the default.
Ensure that the following configuration settings are present in your Microsoft Internet Explorer 6 installation.
To view these settings:
Open Microsoft Internet Explorer 6.
Select the Tools, then Internet Options menu command.
Select the Advanced window tab.
In the Browsing section, ensure that the Reuse windows for launching shortcuts option is selected.
In the Security section, ensure that the Do not save encrypted pages to disk setting is not selected.
In order to properly view CRFs in either Adobe Reader or Acrobat, certain configuration options must be set in a particular way.
Ensure that the following configuration settings are present in your Adobe Reader installation.
Choose Edit, then Preferences, select Options in the Category pane.
Ensure that Display PDF in Browser is selected.
Ensure that Certified Plug-ins Only is clear.
Ensure that Use Page Cache is clear.
Choose Edit, then Preferences, select Forms in the Category pane and ensure that Keep Forms Data Temporarily on Disk is clear.
The application may display a message window that asks you to confirm this choice. Click OK to confirm the setting.
Note:
Adobe Reader 5.1 selects this check box by default each time the application opens. Therefore, you must clear this check box when you start an RDC Classic session.This section describes the information that you must know before you can initiate an RDC Classic session. The information that you should gather is:
Your sponsor or administrator will provide you with a URL that points to the RDC Classic site where you will work. Use this URL to navigate to a site's RDC Classic Launch Page.
Your user name is a unique text string that identifies you to the database. You must use the user name that is assigned to you, since this will help to ensure that you have been granted the necessary database role to complete your work in RDC Classic.
Your password goes with your user name: you must correctly type both and the database name into the appropriate fields of the window in order to successfully log into the RDC Classic system.
Your system administrator typically gives you your password at the same time as your user name. It is your responsibility to keep your password private so as to prevent unauthorized access to the Oracle Clinical databases.
Your system or database administrator will provide you with the name of the database that you will work in when you receive your user name and password.
The database name that you use in the Logon window must match the name of the database in which you have been granted sufficient rights to complete your work. For this reason, you must carefully type the name in the database field.
The database name that you enter in the Logon window determines:
What data you will work with in your RDC Classic session
If you will even be able to access data
This section provides basic information about how certain terms are defined and used in RDC Classic. Its purpose is also to put these terms in context with the entire application.
Note:
You should also consult the Glossary for definitions of terms that are used throughout this guide and in the application.The terms are discussed in the following sections:
An RDC Classic session is the period that starts when you successfully log in to RDC Classic and ends when you exit RDC Classic. An RDC Classic session is constricted by the following requirements:
Only one user name is granted access to a session
The role and privileges assigned to the user name determine the patient data and functionality that is available within a session
Only one database can be accessed during a given session – if you want to access a different database, you must initiate a new RDC Classic session
Only one study can be open at a time during a session, however, unlike the restriction on the active database, you can change to another study within an RDC Classic session – if you want to access a different study you must close the current study and select another
Only one book can be active at a given time, however, you can change to another book within an RDC Classic session
One or more sites can be active during a given session and the privileges assigned to the user name may vary from site to site
The default study is a parameter the system uses to determine which study opens when you start an RDC Classic session.
The presence (or absence) of a value for the default study determines if the Change Study window is displayed during RDC Classic session startup. If a default study value does not exist, the Change Study window is displayed, which provides a mechanism for you to choose a study. This situation is most likely to occur the first time you start an RDC Classic session with a particular database and the system administrator has not defined a default study value.
If a default study value is defined, RDC Classic does not present the Change Study window. Instead, it proceeds to the step in the process in which you select the workset that is displayed in the RDC Classic Spreadsheet, which uses either the Search window or the Activity List window.
In order to streamline the workset selection process, the system attempts to automate initial study selection. When you successfully initiate an RDC Classic session, a study is chosen, if possible, based on your study access, your previous RDC Classic session, or the specification of the system administrator. The following list describes how a study is chosen and when you must manually select a study.
If you have access to one study, that study is automatically selected and you are not provided with the option to change the study during your RDC Classic session.
If you have access to more than one study and a default study is not defined, the system displays the Change Study Window, which you use to choose a study for the RDC Classic session. This case is relevant during your first RDC Classic session in a given database if a default study is not defined by the system administrator.
If you have access to more than one study and a default study is defined, the system does not display the Change Study Window. Rather, the default study is automatically selected and, subsequent to the News window (if applicable), the Activity List window or the Search window is displayed (depending on RDC Classic Configurator settings).
In order to initiate an RDC Classic session, you must have access to at least one RDC Classic-enabled study. An RDC Classic-enabled study is one for which a book is defined. So, while all studies can be opened in Oracle Clinical, only those for which at least one book is defined can be opened in RDC Classic.
This condition has implications for users who have access to more than one study.
If a user has access to more than one study, but only one of that set of studies has a book defined, the user will not have the option to change studies during an RDC Classic session.
If a user has access to more than one study and some, but not all, of those studies are RDC Classic-enabled, the list of values associated with the Select Study window will include all studies to which the user has access. When the user chooses a study for which a default book is not defined, the system displays a message window that describes why the study cannot be opened in RDC Classic and instructs the user to select another study.
Source data is the true representation of the results of a patient's clinical visit. It can be the handwritten "chart" that the doctor completes as a visit proceeds or it can be data recorded directly into RDC Classic.
The purpose of RDC Classic is to facilitate the accurate collection of the information contained in a source data document to the appropriate CRF in the application. By moving this process to the investigator's site, a more efficient and accurate process is assured. Also, if there are any questions about the source data, they can be answered immediately by the person who collected and recorded the information.
You use RDC Classic to send data to the study database that you specify when you initiate an RDC Classic session. Data that you enter in RDC Classic, but which has not been sent to the Oracle Clinical database is termed a "pending change." That is, the data is recorded in RDC Classic, but it has not yet been transmitted to the database. Therefore, an important aspect of your workflow is to understand which data has been saved and which is pending and how to commit pending changes to the database.
The system automatically saves pending changes under certain circumstances. This is referred to as implicit saving. In other cases, you take an action that saves pending changes. This is referred to as explicit saving.
Whenever there are pending changes, you can choose to explicitly save the data. There are several methods you can use:
Press the F10 key.
Open the File menu, and then select Save.
Click the Save button on the toolbar.
In addition, certain other actions cause a confirmation window to be displayed, which allows you to decide if you want to save all pending changes or not (you can also choose to cancel the action and go back to the pending data). The actions that will cause a confirmation window to be displayed are:
Click the "X" in the upper right-hand corner of the Data Entry window to close the window.
Click the "X" in the upper right-hand corner of the Main Application window.
Click the Exit button on the toolbar.
Note:
You are also prompted with a confirmation window when you select the Blank check box in the CRF header.There are several methods to effect an explicit save of pending changes from the Data Entry window:
Press the F10 key.
Click the Save button on the toolbar.
Open the File menu, and then select Save.
Each of these actions causes RDC Classic to immediately save pending changes.
All required fields in the CRF header and CRF section header(s) must contain data before you can explicitly save pending changes.
If all required CRF header and CRF section fields contain data and you have not entered response data, when you manually save the CRF, RDC Classic assigns it the Created entry status. RDC Classic then audits any subsequent updates to CRF header or CRF section header data, using a pre-configured change reason. RDC Classic does not audit changes to response data until the CRF, or CRF section, reaches the Entry Complete data entry status.
Note:
You can view the current entry status of a CRF in the CRF view of the Summary task tab.When data has been entered in a response field and you manually save the CRF, the entry status of the CRF progresses to either Entry Started or Entry Complete, depending on how many sections comprise the CRF and the current status of each. However, the current CRF section is assigned the Entry Complete status and RDC Classic audits subsequent changes to its data.
The entry status of a CRF provides information about the level to which the CRF has progressed in the workflow. RDC Classic also uses it as a trigger for auditing. Although all changes to a CRF are audited after the CRF is saved the first time, the system does not prompt you to enter a change reason and optional comment until the CRF is assigned the Entry Complete data entry status.
There are a large number of instances in which pending changes are saved by the system. While these are based on user actions, a confirmation window is not displayed to prompt you to save pending changes.
There is no warning popup, however, if there is pending data change that requires a user-provided change reason, the Change Reason window is displayed before the Data Entry window is closed.
The actions that will cause the system to automatically save pending changes include:
Initial data entry — Press the Enter or Tab key when focus is in the last response datapoint in the last CRF section (with all required header data entered).
Data update — Click the Save button in the Audit Information window.
Open the Search window, in either New or Modify Search mode.
Change the Page Grouping tab.
Insert a patient.
Use the Validate menu to validate the page, patient, site, or study.
Approve or verify a CRF.
Click the Show/Hide Unplanned Pages button on the Spreadsheet.
Click another CRF icon.
Click another CRF Section tab.
Click another patient in the List of Current Patients.
This section discusses how RDC Classic audits data. It discusses what is audited and the circumstances under which data is audited.
Although response data is of primary importance, auditing also includes changes to CRF and CRF section information, as well as changes in status (for example, approval status), and the discrepancy records.
In order to ensure compliance with regulatory agencies, RDC Classic keeps track of the changes that a particular datapoint undergoes by noting the important information that describes the change to the data. This allows reviewers to track all of the changes that occurred to the data over time and it helps to ensure the integrity of the data.
This information is saved to the database along with the new data, which allows personnel interested in the security and validity of the study to look at the history of each datapoint and ascertain how, when, and why it changed.
Each time a data change occurs, which the system audits, a set of related information is also saved to the database. Table 1-1 describes the audit information saved.
| Information | Description |
|---|---|
|
Username |
The name of the user who changed the datapoint. When an RDC Classic user changes data, the system logs the user name associated with the session and includes it as part of the audit record. |
|
Timestamp |
The date and time that the change took place. his records the time and date that the data was updated. The system uses the timestamp of the database server, however, if your Preferences window settings are configured appropriately, the timestamp you view in RDC Classic is converted to the local time that your computer uses. |
|
Data change |
Describes how the datapoint changed. It includes the original value, the last value, and the new value. |
|
Change Reason |
The system- or user-specified reason that the data changed. This is either a system- or user-selected value that describes why the data was updated. Until a CRF reaches the entry complete data entry status, the change reason is system-selected. After the CRF is at the entry complete status, the system presents an audit information window, which prompts you to select a change reason. You also have the option to include a explanatory comment, which allows you to provide additional information about the data change. |
|
Comment (optional) |
A user-supplied textual description that further explains the data change |
RDC Classic provides you with detailed information through the use of status information that is displayed in several specific areas of the RDC Classic GUI. This section highlights how you can use this information to ensure that the data you enter, update, or verify is associated with the correct patient or other study level criteria.
This section includes the following topics:
The Title Bar of the Main Application Window provides you with key information, such as the:
full name associated with the user name that is logged in
role associated with the user name that is logged in
database name
log in date
name of the study
name of the site
name of the active book
Note:
The site name is not displayed in the title bar if, in the Search Window, you select either:the default site, or
"ALL" sites.
The Spreadsheet status line displays information that reminds you what criteria settings you selected in the Search window.
The default status line, which is displayed when the default values for all Search window criteria are selected, has the following message:
Figure 1-1 Spreadsheet Status Line with Default Search Window Criteria
Use this status information as confirmation that you have selected the default criteria in the Search window.
When you make choices in the Search window that are more restrictive than the default criteria, the Spreadsheet status line is a useful feature because it:
Helps you verify that you have retrieved the data that you intended
Reminds you that you are looking at a subset of the data
You may notice that the Search window gives you text feedback, located adjacent to the relevant criteria label, when you make changes to the parameters of that criteria. If you make changes to more than one criteria, these non-default settings are each listed in the Search window. The status line is simply a compilation of these notices, placed in the Spreadsheet to help you work.
There are many features in RDC Classic that are implemented with the mouse that can also be invoked from the keyboard. The benefit to using the keyboard is efficiency: you can keep your hands stationary while you navigate to and use different features in RDC Classic. This is especially relevant to data entry, which is generally a keyboard-oriented task.
This section provides an overview of how you can use the keyboard to streamline your work in RDC Classic. The topics covered are:
Every menu command can be implemented from the keyboard, as well as by using the mouse cursor. One letter of each menu item is underlined. You can view all of the commands associated with a particular menu item by pressing the Alt key and the letter that is underlined in the desired menu item name.
One letter in each menu command is also underlined. When you expand a menu item, you can then press the key of the letter that is underlined to activate a particular command.
Example 1-1 Using the Insert Menu
The following graphic illustrates using the mouse to activate the Preferences window command on the Insert menu.
To use the keyboard to accomplish this task:
Press Alt+i to display the commands in the Insert menu.
Press m to insert a manual discrepancy for a CRF page.
You can accomplish several tasks more efficiently by using the function keys described in Table 1-2.
Table 1-2 Function Keys in RDC Classic
| Function Key | Description of Associated Action |
|---|---|
|
F1 |
Opens the context-sensitive help topic, if available, for the currently active GUI component. |
|
F7 |
Reads the screen for acceptance of query parameters/values. |
|
F8 |
Executes a query using the values provided. |
|
F9 |
Displays the List of Values (LOV) for a field, if available. |
|
F10 |
In the Data Entry window, this activates an explicit save of all pending changes. |
Use the Tab or the Enter key on the keyboard to navigate from one field to the next in the Data Entry window. Use the Shift+Tab key combination to move back one field.
The name of the currently active study is displayed in the Title Bar of the Main Application Window. It also displays your user name, user role, and the name of the currently active book.
This section discusses roles and privileges in RDC Classic. It is important to understand how the role to which you are assigned and the privileges granted to your user name affect the tasks that you can perform in the application.
RDC Classic uses roles to manage the discrepancy action the user is allowed take and the status of discrepancies for that user. The sponsor assigns a role to each user based on the tasks required of that user.
RDC Classic provides a set of user roles by default. Your sponsor may:
Use these roles, as is
Edit the roles
Add new roles
Table 1-3 describes the default user roles.
Privileges are statuses that are assigned to each user name that give the user access to certain data and CRFs, as well as permission to perform certain tasks. Privileges are independent of roles (which are described in "Roles"), however, sponsors often assign the same set of privileges to all users in a particular role.
The system administrator assigns each user name a set of privileges through RDC Classic Administration. Most privileges can be assigned at the study- or site-level, however, several can only be assigned at the site-level. Table 1-4 describes the privileges that are available in RDC Classic.
Table 1-4 Privileges in RDC Classic
| Privilege (Short) | Privilege (Long) | Scope (Study or Site) | Description |
|---|---|---|---|
|
BROWSE |
Browse |
Both |
User can open a non-batch loaded CRF and view its data. |
|
BRW_BATCH |
Browse Batch Data |
Both |
User can open a batch loaded CRF and view its data. |
|
UPD_DISCREP |
Update Discrepancy |
Both |
User can modify the discrepancy records in a CRF. |
|
UPD_BATCH |
Update Batch Data |
Both |
User can update batch loaded CRFs. |
|
UPDATE |
Update Data |
Both |
User can update non-batch loaded CRFs. |
|
VERIFY |
Verify CRF |
Both |
User can change the verification status of a CRF. |
|
APPROVE |
Approve CRF |
Site |
User can change the approval status of a CRF. |
|
LOCK |
Lock CRF |
Both |
User can lock any CRF. |
|
UNLOCK |
Unlock CRF |
Site |
User can assign to users the ability to access and update a CRF in locked status. |
In order to have access to RDC Classic, all users must, at a minimum, be assigned the browse privilege for a study or a site. If the system determines at login that the user is not assigned at least this privilege, it will not permit the RDC Classic session to start.
As described in "Inclusion", all other privileges include the browse privilege. This means that all RDC Classic users must be assigned at least one privilege in order to start a session.
Batch loaded CRFs are a distinct type of CRF for which separate privileges must be assigned to your user name in order to view and update data. These two privileges, browse batch and update batch, allow you to access and update batch loaded CRFs. Note that the other actions that change the status of a CRF are the same for batch loaded as for non-batch loaded data. That is, a user with the verify, approve, lock, or unlock privilege is able to take action on batch and non-batch loaded CRFs. However, whereas the browse privilege is included in these privileges, the browse batch privilege is not. Therefore, a user with one of these privileges must also have the browse batch (or update batch) privilege in order to open and view a batch loaded CRF.
The update batch privilege gives you access to update data in a batch loaded CRF. However, unlike the update privilege, which includes the update discrepancy privilege, update batch only permits you update response data and investigator comments. In order to update discrepancies in a batch loaded CRF, the update discrepancy privilege must be assigned to your user name.
Certain privileges include the permissions that comprise another privilege, in addition to different permissions. The browse privilege is the primary example of this kind of inclusion. As discussed in "Minimum Requirement", all RDC Classic users must be assigned the browse privilege in order to start a session. However, all other privileges include the permissions in browse. Consequently, if your user name is assigned to any privilege other than browse, it is not necessary that the browse privilege is also assigned to you.
The only situation in which the browse privilege must be assigned to your user name (in order to start a session) is if no other privileges are assigned.
For example, if a user is assigned the update privilege, it is not necessary to also assign the browse privilege to the user. The update privilege includes permission to open a CRF and view response data.
Table 1-5 defines the privileges that are included in other privileges.
All privileges except approve and unlock can be assigned at the site- and the study-level. However, the set of privileges that are assigned at the site-level take precedence over those that are assigned at the study-level. In situations where the administrator assigns privileges to users on a site basis only, precedence between the site and study levels has no affect. Similarly, when privileges are assigned on a study basis only, the permissions that are granted are not altered because no site-level privileges have been assigned. However, for those users who are assigned privileges at both the study- and the site-level, it is important to review how RDC Classic processes the permissions that each privilege grants.
You can use the method in which RDC Classic applies privileges at the site- and study-level to either ensure a user has access to all study-level privileges at all sites. Refer to Example 1-2, "Assigning Site- and Study-level Privileges to Provide Full Access" for an illustration of this use.
Alternatively, you can use precedence of site- over study-level privileges to limit the access a user has to individual sites. Refer to Example 1-3, "Using Site- and Study-level Privileges to Limit Access" for an illustration of this use.
If a user is granted one set of study-level privileges and a different set of site-level privileges at one or more sites in that study, the site-level privileges take precedence over the study privileges at those sites. This means that the study-level privileges are not in affect at those sites. For all other sites, that is, those for which site-level privileges are not assigned, the study-level privileges are in affect.
Example 1-2 Assigning Site- and Study-level Privileges to Provide Full Access
For a study that is comprised of sites Site001 through Site006, if a user is assigned the update privilege at the study level, the user is allowed to update data and discrepancies at all sites in the study. If that user is assigned the approve privilege (only) at Site001 and Site003, the user still has update permission at all sites except those sites. At Site001 and Site003, the user would be able to browse data (refer to "Inclusion") and approve CRFs, but not update data. In order to allow the user to update data at all sites in the study, the administrator would have to also assign the user site-level update, as well as approve, at Site001 and Site003.
Essentially, if you require a certain privilege (PrivilegeA) at all sites in a study and a different privilege (PrivilegeB) at some smaller set of sites (Site2 and Site4), your user name must be assigned:
PrivilegeA at the study-level, and
PrivilegeA and PrivilegeB at Site2 and Site4.
An exception to this requirement is where privileges are included in other privileges. For example, if, in the preceding scenario, Privilege A is the browse privilege, only Privilege B must be assigned at the relevant sites because all privileges include the browse privilege.
You can also use the precedence of site- over study-level privileges to restrict the access a user has to specific sites. The situation described in Example 1-3 illustrates how an administrator can limit the privileges of a user for a specific site.
Example 1-3 Using Site- and Study-level Privileges to Limit Access
For a study that is comprised of sites Clin001 through Clin006, if an administrator wants a user to have permission to update data at all sites, except Clin003, the following privileges should be assigned to that user:
study-level update, and
site-level browse at Clin003.
Because privileges at the site-level take precedence over study-level, browse is the only privilege that has affect at Clin003. This effectively limits the user to view-only access to all CRFs associated with patients assigned to Clin003.
The site criterion, which is a constituent of the search criteria, can either be <ALL>, that is, all sites to which you have access, or a single site to which you have access. As illustrated in Table 1-4, "Privileges in RDC Classic", the approve and unlock privileges can only be assigned at the site-level. These site-level only privileges are directly impacted by the setting of the site criterion. In order to have access to tasks that these privileges provide, the search criteria must be a site for which the relevant privilege has been assigned to you user name.
Example 1-4 Effect of Search Criteria on Access Site-level Privileges
For a study that is comprised of sites Clin001 through Clin006 and a user with the following privileges:
Study-level: update
Site-level: approve at Clin003.
If the site criterion is set <ALL>, either through the Search window or by selecting a study node task in the Activity List window, the system will not allow the user to alter the approval status of any CRFs, including those for patients assigned to Clin003. In addition, the user will only be able to browse CRFs for patients assigned to Clin003.
If the site criterion is set to Clin003, the RDC Classic Spreadsheet displays only those CRFs that are associated with patients assigned to Clin003. In this case, the system will give the user access to change the approval status of any CRF in the workset.
This section describes typical workflows in RDC Classic that must be completed. Although the RDC Classic documentation is structured in a manner that is not role-specific, there are certain assumptions made about the tasks that must be completed as part of a clinical study which are mimicked in the manual and the online help system.
This section discusses the process of initial data entry.
Although variations in protocols and CRF design preclude all but the most general workflow description, it is instructive to define a "typical" initial data entry sequence of events. This typical case assumes that at least a portion of the source data required to complete the CRF, or the CRF section, is available.
In such a case, the general sequence proceeds from clicking a CRF cell, which opens the Data Entry window, entering all required header data, and completing response data fields. When you save this CRF, RDC Classic assigns it the Entry Complete status.
Table 1-6 lists the steps and outlines a general sequence of events for initial data entry.
Table 1-6 General Workflow for Initial Data Entry
| Data Entry Status | Step | Description/Comment |
|---|---|---|
|
Created |
Open the CRF |
RDC Classic assigns a provisional data entry status of Created. |
|
Created |
Complete all required CRF header fields |
Focus automatically moves to either the first required CRF section header field (for example, "Visit Date") or, if the CRF section header is not present, the first response field in the question area. |
|
Created |
If CRF section header is present, complete all required fields |
Focus automatically moves from last CRF section header field to first response field. |
|
Entry Started |
Enter response field data |
When the CRF is saved with any response data (including investigator comments), the data entry status changes to Entry Complete |
|
Entry Complete |
Save the CRF |
You can save the CRF explicitly, for example, by pressing the F10 key; or implicitly, by closing the CRF and choosing to save changes when RDC Classic prompts you. RDC Classic audits subsequent changes to the CRF header fields (both required and optional). |
In this case, you collect only the minimum data that the system requires to save the CRF. Once you save it, RDC Classic assigns it the Created data entry status. By implication, response data is not collected in the process.
Note that for multi-section CRFs, each section is assigned an entry status that is independent of the CRF and the other sections. However, when you initially open the CRF, the CRF and all of its sections are simultaneously assigned the Created data entry status.
This process differs slightly for single- and multi-section CRFs because all required section header fields must be complete before you can save the CRF. In most cases, a section header is not present in single-section CRFs, and if present, RDC Classic automatically places focus in the required section header fields when you complete the required CRF header fields. However, for multi-section CRFs, after you complete any required section header fields in the first section, you must navigate to other sections to collect required header fields before you can save the CRF to the study database.
The workflow described in Table 1-7, "Workflow to Save CRF in Created Status – Single-section CRF" describes the general process of opening a single-section CRF, collected required header fields, and saving the CRF in Created data entry status.
Table 1-7 Workflow to Save CRF in Created Status – Single-section CRF
| Data Entry Status | Step | Description/Comment |
|---|---|---|
|
Created |
Open the CRF. |
RDC Classic assigns the CRF a provisional data entry status of Created |
|
Created |
Complete all required CRF header fields |
Focus automatically moves to either the first required CRF section header field or, if CRF section header is not present, the first response field in the question area. |
|
Created |
If CRF a section header is present, complete all required fields in the section. |
Focus moves from last CRF section header field to first response field. |
|
Created |
Save the CRF |
You can save the CRF explicitly, for example, by pressing the F10 key; or implicitly, by closing the CRF and choosing to save changes when RDC Classic prompts you. In either case, RDC Classic saves the data entry status with the CRF. RDC Classic prohibits the save action if there are required header fields that are not collected. RDC Classic audits subsequent changes to the CRF header fields (both required and optional). |
The workflow described in Table 1-8, "Workflow to Save CRF in Created Status – Multiple-section CRF" describes the general process of opening a multi-section CRF, collecting all CRF and CRF section header data, and saving the CRF in Created data entry status.
Table 1-8 Workflow to Save CRF in Created Status – Multiple-section CRF
| No | Step | Description/Comment |
|---|---|---|
|
1 |
Click the CRF cell to open the CRF. |
Focus moves from last CRF section header field to first response field in the section. |
|
2 |
Complete all required CRF header fields |
Focus automatically moves to either the first required CRF section header field or, if CRF section header is not present, the first response field in the question area. |
|
3 |
If CRF a section header is present, complete all required fields in the section. |
Focus moves from last CRF section header field to first response field in the section. |
|
4 |
Navigate to each section header and complete required fields. |
In each section, focus moves from last CRF section header field to the first response field in the section. |
|
5 |
Save the CRF |
You can save the CRF explicitly, for example, by pressing the F10 key; or implicitly, by closing the CRF and choosing to save changes when RDC Classic prompts you. In either case, RDC Classic saves the data entry status with the CRF. RDC Classic prohibits the save action if there are required header fields that are not collected. RDC Classic audits subsequent changes to the CRF header fields (both required and optional). |
Note that the Created data entry status is not actually assigned until you save the CRF. Prior to that, if you close the CRF without saving changes, the CRF reverts to the Not Created status.
In this case, you complete the tasks required to create the CRF and then continue to collect response data. There are significant differences between the workflow for single-section CRFs, which represents the simpler case, and that for multi-section CRFs.
The sequence described in Table 1-9, "Workflow to Create a CRF and Proceed to Data Entry – Single-section CRF" assumes that you complete all required header fields and initiate data entry in the Question section prior to saving the single-section CRF.
Table 1-9 Workflow to Create a CRF and Proceed to Data Entry – Single-section CRF
| No | Step | Description/Comment |
|---|---|---|
|
1 |
Click the CRF cell to open the CRF. |
RDC Classic assigns the CRF a provisional data entry status of Created |
|
2 |
Complete all required CRF header fields |
Focus automatically moves to either the first required CRF section header field or, if CRF section header is not present, the first response field in the question area. |
|
3 |
If the CRF section header is present, complete all required fields. |
Focus automatically moves from last CRF section header field to first response field. |
|
4 |
Enter response data in the Question area. |
Use the Tab or Enter key to navigate to subsequent response fields. |
|
5 |
Save the CRF |
You can save the CRF explicitly, for example, by pressing the F10 key; or implicitly, by closing the CRF and choosing to save changes when RDC Classic prompts you. In either case, RDC Classic saves the data entry status with the CRF. RDC Classic audits subsequent changes to the CRF header fields (both required and optional) and response data. |
Data entry for a multi-section CRF is more involved than for a single-section CRF. Several points are pertinent to the process:
You must complete all required section header fields for a given section before RDC Classic allows you to initiate data entry in the Question area of that section.
You must complete all required section header fields for all sections before RDC Classic allows you to save the CRF.
RDC Classic assigns a data entry status to the CRF that is based on the data entry status of its sections:
If all sections are at the same status, that is, either Created or Entry Complete, the RDC Classic assigns that status to the CRF
RDC Classic assigns the CRF the data entry status Entry Started under the following conditions:
One section is at Created and all others are at Entry Complete
One section is at Entry Complete and all others are at Created
The sequence listed and described in Table 1-10, "Workflow to Create a CRF and Proceed to Data Entry – Multi-section CRF" outlines a procedure to complete the required header fields and start collecting response data in the Question area.
Table 1-10 Workflow to Create a CRF and Proceed to Data Entry – Multi-section CRF
| No | Step | Description/Comment |
|---|---|---|
|
1 |
Open the CRF |
RDC Classic assigns the CRF a provisional data entry status of Created |
|
2 |
Complete all required CRF header fields |
Focus automatically moves to either the first required CRF section header field. |
|
3 |
Complete all required CRF section header fields for the section in which you want to enter data. |
Focus automatically moves from last CRF section header field to first response field. To initiate data entry in a given section, only the required section header fields for that section must be complete. However, all required section header fields must be complete in order to save the CRF. |
|
4 |
Enter response data in the Question area of the first section. |
RDC Classic automatically navigates from last data entry field in current section the first required section header field in the next CRF or the first response field in the Question area. |
|
5 |
Complete required CRF section fields in next section. |
When focus moves to next section, RDC Classic assigns the Entry Complete data entry status to the first CRF section and Entry Started to the entire CRF. |
|
6 |
Enter response data in the Question area of the next CRF section. |
Repeat this step until all sections are complete. |
|
7 |
Save the CRF |
You can save the CRF explicitly, for example, by pressing the F10 key; or implicitly, by closing the CRF and choosing to save changes when RDC Classic prompts you. In either case, RDC Classic saves the data entry status with the CRF. RDC Classic audits subsequent changes to the CRF header fields (both required and optional). |
When a CRF or CRF section is saved in the Entry Complete data entry status, all mandatory fields in the Question area(s) that do not contain data generate a "Missing Mandatory Field" discrepancy. RDC Classic will close these type of discrepancies with a reason of "Resolved" when data is collected for the missing field.
RDC Classic gives you the capability to generate either a patient data report (PDR) or a workbook report. The PDR can incorporate the patient data that is present in the current workset or you can specify a different workset. You can generate the workbook report either with or without information for a specific patient included in the CRF and CRF section header areas. Table 1-11 outlines the basic workflow for this task.
Table 1-11 Workflow to Run a Report
| No. | Step | Comment | Reference |
|---|---|---|---|
|
1 |
In the RDC Classic Workspace, select File, then Reports. |
If you want to run a PDR using current selections, you should ensure the search criteria is correct and that workset has been refreshed before you open the Reports window. |
|
|
2 |
In the Reports window, select the type of report you want to run. |
You can choose to run a PDR or a workbook report. |
|
|
3 |
If desired, you can resume working in RDC Classic while the report runs. |
The report may take an extended period of time to run, depending on the number of CRF s and the amount of data it contains. |
|
|
4 |
Check the progress of the report process. |
You can periodically monitor the progress of the report. |
|
|
5 |
Review the report and print it, if desired. |
The report is generated as a PDF document that you can save locally or print. |
This section presents a general workflow scenario that illustrates how the unlock privilege may be used. Essentially, the unlock procedure is designed to provide a mechanism to make discrete updates to CRFs that have been locked.
Refer to "Unlock a CRF" for specific information about the unlock procedure.
Table 1-12 Workflow to Unlock a CRF for Update
| No. | Step | Comment | Reference |
|---|---|---|---|
|
1 |
The data manager assigns to one or more users the capability to modify a locked CRF. |
The DM must be assigned the unlock privilege at the current site. Only users who can update the CRF should be given access to the locked CRF. |
|
|
2 |
A designated user (with appropriate privilege) opens the CRF. |
The user must know the correct CRF to open, since the icon continues to reflect locked status. |
"Update Response Data for a CRF" |
|
3 |
The data manager removes all names from the list of users who can update the CRF. |
When no users are listed, the CRF is locked and cannot be updated. |
|
 Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
