| Oracle® Clinical Remote Data Capture Classic Data Entry User's Guide Release 4.6 B13921-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Clinical Remote Data Capture Classic Data Entry User's Guide Release 4.6 B13921-03 |
|
|
PDF · Mobi · ePub |
System administration for RDC Classic requires that you perform certain tasks in Oracle Clinical and others in RDC Classic Administration. This section describes the tasks you perform in Oracle Clinical. Refer to "RDC Classic Administration Tasks" for the tasks that you complete in RDC Classic Administration.
RDC Classic requires certain reference codelists and a form for setting security at remote sites. All codelists are type INSTALLATION.
This section covers the following topics:
RDC Classic users require Oracle database accounts like other Oracle Clinical users. RDC Classic recognizes the following database roles in addition to the Oracle Clinical roles:
All RDC Classic users must be granted the role that matches their job function (refer to the Oracle Clinical Administrator's Guide for a complete list and additional instructions). The USER GROUP ROLES reference codelist coordinates a database role with an RDC Classic user group.
Within RDC Classic, user groups control the appearance of discrepancies and the functions that users can perform. You configure the user groups in the User group roles reference codelist.
An RDC Classic user group is a named set of system users who are assigned the same RDC Classic role. It is not the same as an Oracle group user account.
The USER GROUP ROLES reference codelist defines the number and names of the user groups for an installation. Refer to the Oracle Clinical Administrator's Guide for information on this codelist.
You cannot delete a user group's codelist entry, but you can deactivate it by clearing its Active? checkbox. You can add user groups by inserting records as usual. (Refer to "Set Up a New User Group" for details on creating custom user groups.)
The installation reference codelist USER GROUP ROLES maps Oracle database roles to the named RDC Classic user groups. That is, when users log into RDC Classic, the database role granted to their Oracle account is compared to the Short Values in the reference codelist and the first match, in order of priority, determines the user group to which the user is assigned. Refer to the Oracle Clinical Administrator's Guide for information on the USER GROUP ROLES codelist.
If you have the RXC_SUPER or RXC_ADMIN database roles you can create new user group definitions. First you assign a name to the user group, then you set its role.
To define a new user group:
Navigate to Admin, then Reference Codelists, and Installation Codelists menu path. The system displays the Maintain Installation Codelists window.
Query for the codelist, "USER GROUPS".
Use the Data, then Insert Record menu command to insert a record in the Reference Codelist Values section. Type the new group name in the Short Value field.
Save pending changes.
Query for "USER GROUP ROLES".
Use the Data, then Insert Record menu command to insert a record in the Reference Codelist Values section.
Type the group name in the Long Value field.
Type the database role in the Short Value field.
Save pending changes.
Use the Data, then Insert Record menu command to insert a record in the Reference Codelist Values section.
Type the group name in the Long Value field.
Type the default change reason in the Short Value field (refer to "Setting the Change Reason" for details).
Save pending changes.
In order to use the new user role in RDC Classic, you must create a mechanism that allows discrepancies to be assigned a status for the role and a setup a group of actions that members of the role can take on a discrepancy. You do this by creating two new installation reference codelists:
DISCREPANCY ACTIONS <user group name>
DISCREPANCY STATUS <user group name>
Connect to the database as OPA and, in SQL*Plus:
If needed, create a new database role for the user group. (Refer to the Oracle Clinical Administrator's Guide for information on adding roles to Oracle Clinical.)
If you plan to use existing Oracle Clinical roles, such as RXC_DMGR, proceed to Step 2.
Create the installation reference codelists DISCREPANCY ACTIONS <user_group> and DISCREPANCY STATUS <user_group>.
To do this, you can copy, paste, and edit the appropriate sections of the SQL script that creates reference codelists. This script is RDCpopulatedata.sql in the install directory.
In the RDC Classic Spreadsheet, a CRF icon represents each CRF in which data has been recorded. The system colors those CRFs with open discrepancies either red or yellow, depending on the discrepancy status for the current user. CRFs with at least one open discrepancy that is actionable by the current user's role are red. Those with at least one open discrepancy that is actionable by a different role are yellow. Active (red) discrepancies take precedence over other (yellow) discrepancies, so the system colors a CRF with both active and other discrepancies red.
You setup the discrepancy indicators and actions with two sets of installation reference codelists. You also set the default reason given for a data change per user group in a reference codelist.
The coloring of CRF icons with regard to discrepancies in the RDC Classic Spreadsheet are shown in Table 17-1.
Table 17-1 RDC Classic Discrepancy Icons and Statuses
| Icon | Status | Implication |
|---|---|---|
 |
ACTIVE |
The CRF contains at least one open discrepancy that requires attention by the user group to which the current user is assigned. |
 |
OTHER |
The only open discrepancies in the CRF require the attention of a user group different than the one to which the current user is assigned. |
 |
CLOSED |
The CRF contains no open discrepancies – either it never contained discrepant data or any discrepancies have been resolved/closed. |
When Oracle Clinical is installed, an installation reference codelist named DISCREPANCY STATUS ROLE is created for each of the default user groups: CRA, DM, INV, and SITE. (Refer to the Oracle Clinical Administrator's Guide for additional information about these codelists.) Each codelist maps the Oracle Clinical discrepancy review statuses to the RDC Classic discrepancy statuses appropriate to the user group. Table 17-2 shows the default discrepancy statuses for each user group.
Table 17-2 User Groups and Default RDC Classic Discrepancy Statuses
| Short Value – Oracle Clinical Discrepancy Review Status | Long Value – RDC Discrepancy Status | |||
|---|---|---|---|---|
| CRA | DM | INV | SITE | |
|
UNREVIEWED |
ACTIVE |
ACTIVE |
ACTIVE |
ACTIVE |
|
CRA REVIEW |
ACTIVE |
OTHER |
ACTIVE |
ACTIVE |
|
INV REVIEW |
ACTIVE |
OTHER |
ACTIVE |
ACTIVE |
|
DM REVIEW |
OTHER |
ACTIVE |
OTHER |
OTHER |
|
TMS EVALUATION |
OTHER |
OTHER |
OTHER |
OTHER |
|
TMS IN PROGRESS |
OTHER |
OTHER |
OTHER |
OTHER |
|
RESOLVED |
CLOSED |
CLOSED |
CLOSED |
CLOSED |
|
IRRESOLVABLE |
CLOSED |
CLOSED |
CLOSED |
CLOSED |
|
CLOSED |
CLOSED |
CLOSED |
CLOSED |
CLOSED |
For example, putting Table 17-1 and Table 17-2 together, a user in the DM group would see a discrepancy of review status DM REVIEW as having a red icon, while a user in the SITE group would see the same discrepancy as yellow.
Note that the discrepancy review status does not determine what functions a user can perform on the discrepancy or the patient data. Refer to the next section, and "Setting Study/Site Security Privileges". Refer to the DISCREPANCY ACTIONS ROLES codelists in the Oracle Clinical Administrator's Guide to determine what routing and resolution actions each user role can take on a discrepancy.
In RDC Classic, a user changes the review status of a discrepancy by choosing an item from a drop-down list box. The installation reference codelists DISCREPANCY ACTIONS ROLE Codelists define which items are available to each user group.
There is a codelist for each named user group, by default DM, CRA, SITE and INV. For example, Table 17-3 shows the entries for DISCREPANCY ACTIONS DM.
When an RDC Classic user updates a CRF that is in the entry complete data entry status, the system displays an Audit Information window, which prompts the user for a change reason. The user must select the change reason from a list of values. The list of values is defined in a reference codelist that you maintain. By altering the values in the codelist, you can choose which is the default reason and you can modify existing or add new entries that suit your business requirements.
The change reason list of values is populated by the entries in the installation reference codelist. Refer to the DATA CHANGE REASON TYPE CODE codelist in the Oracle Clinical Administrator's Guide for more information. You can modify this codelist to alter the choices that the system presents to the user who modifies an accessible CRF.
To set the default data change reason for a user group, put the group name in the Long Value field of that reason code (Short Value column). Table 17-4 lists several example entries. You can also put a comma-separated list of roles in a single field.
Note that changing the Long Value of a DATA CHANGE REASON TYPE CODE entry has no effect on data entry through the standard Oracle Clinical forms. This feature is available in RDC Classic only.
RDC Classic users can add unplanned CRFs and visits using commands in the RDC Workspace. Refer to the SINGLE DCI TYPES codelist in the Oracle Clinical Administrator's Guide for the CRFs that an end user cannot add.
When an RDC Classic user adds an unplanned visit, by choosing Visit in the Insert menu, the system creates a visit with all the DCIs from the previous scheduled visit, except for any DCI whose DCI type, as entered in the DCI definition screen, has an entry in SINGLE DCI TYPES. Similarly, when an RDC Classic user adds an unplanned CRF, by choosing CRF in the Insert menu, the system presents the user with a LOV comprised of all DCIs not yet included in the current visit, except for those listed in the codelist.
This section describes how to maintain and create standard messages that are displayed to the user during data entry and discrepancy management.
The system displays customized text to RDC Classic users when the system generates a univariate discrepancy as the result of a validation error.
Table 17-5 Customizable Univariate Discrepancy Messages
| Discrepancy Type (Short Value) | Default Text (Description) |
|---|---|
|
DATA TYPE |
Value of \VALUE_TEXT\ for \SAS_LABEL\ is not a valid \DATA_TYPE\ |
|
DVG |
Value of \VALUE_TEXT\ for \SAS_LABEL\ not found in \DISCRETE_VALUES\ |
|
DVG SUBSET |
Value of \VALUE_TEXT\ for \SAS_LABEL\ not found in \DISCRETE_VALUES\ |
|
LENGTH |
Value of \VALUE_TEXT\ for \SAS_LABEL\ exceeds expected length of \LENGTH\ |
|
LOWERBOUND |
Value of \VALUE_TEXT\ for \SAS_LABEL\ below minimum value of \LOWER_BOUND\ |
|
MANDATORY |
Value for \SAS_LABEL\ has not been supplied |
|
MISSING_PT |
Value of \VALUE_TEXT\ for \SAS_LABEL\ is awaiting classification |
|
MISSING_SCT |
Value of \VALUE_TEXT\ for \SAS_LABEL\ is awaiting classification |
|
PARTIAL DATE |
Value of \VALUE_TEXT\ for \SAS_LABEL\ is an incomplete date or time |
|
PRECISION |
Value of \VALUE_TEXT\ for \SAS_LABEL\ exceeds \DECIMAL_PLACES\ decimal places |
|
THESAURUS |
Value of \VALUE_TEXT\ for \SAS_LABEL\ is not in the lookup thesaurus |
|
UPPERBOUND |
Value of \VALUE_TEXT\ for \SAS_LABEL\ above maximum value of \UPPER_BOUND\ |
The discrepancy type codes are defined in a System reference codelist and cannot be modified. Table 17-6 describes the substitution variables.
Table 17-6 Substitution Variables for Univariate Discrepancy Messages
| Name | Description |
|---|---|
|
\ASSOC_ID\ |
ID number of the associated discrepancy. |
|
\CRF_PAGE_NO\ |
Page number of the question in the Case Report Form. |
|
\DATA_TYPE\ |
Data type of the question. |
|
\DATE_TIME_FMT\ |
Date time format (for example, DD-Mon-YYYY) |
|
\DCM_NAME\ |
DCM Name |
|
\DCM_PROMPT\ |
Question prompt |
|
\DCM_SUBSET\ |
DCM Subset number |
|
\DECIMAL_PLACES\ |
Number of decimal places |
|
\DESCRIPTOR1\ |
Descriptor for a repeating question group |
|
\DVG_NAME\ |
DVG name |
|
\LENGTH\ |
Length of question |
|
\LOWER_BOUND\ |
Lower limit of a range of allowable values. |
|
\REPEAT_SN\ |
Sequence number of the question in a repeating question group. |
|
\SAS_LABEL\ |
SAS label |
|
\SAS_NAME\ |
SAS name |
|
\UPPER_BOUND\ |
Upper limit of a range of allowable values. |
|
\VALUE_TEXT\ |
Value of the response |
|
\DEFAULT_PROMPT\ |
Default prompt for the question. |
|
\DISCRETE_VALUES\ |
Allowable values as a comma-delimited list. |
The News system provides a bulletin board method of communication with RDC Classic users.
You can customize the content that RDC Classic users see in the News window. You can also add custom code to the PL/SQL functions that display that content.
Note that Oracle does not officially support this feature.
To customize the content of the News window, select the Maintain News node from the RDC Classic Administrator menu tree. The system displays the News definition for RDC window, which is depicted in Figure 17-2.
You can define one or two news items for the user to read on starting RDC Classic. The items can vary according to:
The study
A site within the study
A user account id (for example, OPS$JSMITH)
A user group role (for example, CRA)
A time frame
A priority (1 is highest, 5 lowest)
Position on the screen (1 is upper, 2 lower)
Note that if you target a news item to one particular site, the only users who see it are those who access to only that site. The News window appears before users choose their site, if they have access to more than one.
For both news items, you can specify:
A headline (shown in blue, refer to Figure 17-1) and body content
A label for the command button
The URL to access on clicking the button
You can use the following substitution parameters within the News field:
This package contains PL*SQL procedures that you can modify to customize various aspects of the RDC Classic system's behavior. Oracle requires that you modify only the code in the package body (file RDCpb_client.sql). Do not modify the package specification (file RDCps_client.sql).
Table 17-7 describes the contents of the RDC_CLIENT package.
Table 17-7 Contents of Package RDC_CLIENT
| Name | Description |
|---|---|
|
Configures the display of the RDC Classic News window |
|
|
Determines which RDCIs are displayed in the RDC Classic Spreadsheet |
|
|
Derives an identification number from the key fields of the document. It can be used to differentiate between RDC Classic- and Oracle Clinical-created RDCIs based on document number |
|
|
Sets the timeout period for the display of password confirmation windows during the CRF approval process |
|
|
Populates the explanatory text that is displayed in the Approval Password confirmation windows that is presented during the CRF approval process |
|
|
Populates the explanatory text that is displayed in the Undo Approval Password confirmation window that is presented during the CRF undo approval process |
|
|
Performs string substitution on text supplied in the News Definition form |
|
|
Retrieves the appropriate configuration name for the current user, based on the assignment parameters |
|
|
Populates the explanatory text that is displayed in the Group Approval Password confirmation window, which is presented during the Approve CRFs process |
|
|
Populates the explanatory text that is displayed in the Group Undo Approval Password confirmation window, which is presented during the Undo Approved CRFs process |
pStudy (in varchar2) — Name of the study to receive the news.
pSite (in varchar2) — Name of a site within the study.
pRole (in varchar2) — Name of a user group role (for example, DM, CRA).
pUser (in varchar2) — Userid of a person at the site.
pTitle1 (out varchar2) — Headline for first (upper) news item.
pNews1 (out varchar2) — Content of first news item.
pLabel1 (out varchar2) — Label for more information button for first news item.
pURL1 (out varchar2) — URL linked to by first button. If null, button is disabled.
pTitle2 (out varchar2) — Headline for second (lower) news item.
pNews2 (out varchar2) — Content of second news item.
pLabel2 (out varchar2) — Label for more information button for second news item
pURL2 (out varchar2) — URL linked to by second button. If null, button is disabled.
pSite (in) — Name of the site name
pMode (in) — Kind of environment: T for Test or P for Production
pRdciId (in) — Identification number of the Received DCI
pRdciStatus (in) — Status code of the Received DCI
pUpdateSitelist (in) — Comma-separated list of sites with "Update batch"
pBrowseSitelist (in) — Comma-separated list of sites with "Browse batch"
In the RDC Classic main window, the users with update access see a disk icon on a white background. Double-clicking the icon opens the Data Entry window in update mode.
Users with browse access see a disk icon on a gray background. Double-clicking the icon opens the Data Entry window read-only.
Users with no access to batch loaded data also see the icon on a gray background, but double-clicking opens only the CRF header pane, not the whole Data Entry window.
This function allows you to derive an identification number from the key fields of the document. Modify the code according to your business rules. For example, you could make the site number part of the document number.
study (in varchar2) — The name of the study.
clinical_study_id (in number) — The ID number of the study.
patient (in varchar2) — The external identifier (code name) of the patient.
patient_position_id (in number) — The patient's position number.
investigator (in varchar2) — The code name of the investigator.
investigator_id (in number) — The ID number of the investigator.
site (in varchar2) — The code name of the site.
site_id (in number) — The ID number of the site.
DCI (in varchar2) — The name of the Data Collection Instrument.
dci_id (in number) — The ID number of the DCI.
event (in varchar2) — The name of the clinical planned event.
clin_plan_eve_id (in number) — The ID number of the clinical planned event.
subevent (in number) — The ID number of a subtype of the planned event.
rxc_env_type (in varchar2) — Environment type: T for Test or P for Production.
Sets the limit on idle time between prompts for password confirmation for electronic signatures and source data verifications.
This is a local function that is only found in the package body.
Called by procedure News; performs string substitution on text supplied in the News Definition form (refer to ).
News item with substitution variables replaced by substrings.
varchar2 is vOut varchar2(500); nPos pls_integer; dEnd date; vName varchar2(70);
This function processes the assignment parameters in the RDC Classic Configurations settings to determine the configuration module of the current user.
Four configurations are shipped as part of the installation: three use role-based assignment parameters and the one is the default for all other users. If the user's role is INV, CRA, or SITE, the corresponding configuration name is returned. If the user's role is not one of those, the Default configuration is returned.
This function populates the explanatory text that is displayed in the Approval Password Confirmation window, which is presented when the user selects the Group Activities, then Approve CRFs menu command.
This function populates the explanatory text that is displayed in the Password Confirmation window, which is presented when the user selects the Group Activities, then UNDO Approved CRFs.
|
 Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
