| 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 |
The process of discrepancy management entails all of the tasks that are related to working with discrepancies. This process is critical to successful clinical data management because it allows you to ensure that the collected patient data is as free of errors and inaccuracies as possible.
This section describes what discrepancies are, how discrepancies are classified, and how you use RDC Classic to manage discrepancies. It includes these topics:
A discrepancy is a query, or question, that calls attention to one or more datapoints in a CRF or a CRF section. The goal of discrepancies is to ensure that all data collected in a CRF is accurate. RDC Classic permits users and the system to take various actions on a discrepancy, with the goal of resolving all discrepancies to ensure clean data. For each occurrence of a discrepancy, a user has the ability to address the issue the discrepancy raises and take action on it.
In addition to alerting users to a potential problem with the data, a discrepancy facilities communication between users. By focusing communication on a single issue, the narrow scope of a discrepancy allows users to perform discrepancy management and safety reviews in an orderly, item-by-item basis.
Some examples of situations that result in a new discrepancy are:
An edit check of a response field where the recorded value is eight characters long and the question definition specifies a maximum of six characters
A validation procedure identifies that the value for the systolic pressure is less than the value for the diastolic in a given CRF
A user wants to include a note with the response field that describes a legibility problem with the source data.
Each of these situations causes the system to initiate a new discrepancy. When a discrepancy is raised, RDC Classic users can take actions on it until it is resolved. These actions comprise the process of discrepancy management. The goal of discrepancy management is to satisfactorily close all discrepancies that are raised.
Each discrepancy is described by a discrepancy record, which maintains the pertinent information necessary to uniquely identify it. The contents of the discrepancy record provide the specific reasons the discrepancy was raised, the user responsible for its initiation or update, the timestamp of each action, and related information that is necessary for users to perform discrepancy management tasks.
The section is comprised of the following topics:
At the most general level, the discrepancy is described based on how it originates. In RDC Classic, a discrepancy can be initiated in one of two ways:
System-generated – also referred to as a data discrepancy
User-generated – also referred to as a manual discrepancy
Each type is described in the following subsections:
The purpose of a system-generated discrepancy is to alert users that there may be a problem with a response value, or a group of response values. This may be related to the values recorded in the CRF(s) or it could be due to responses for which data has not been collected.
Table 3-1 describes the three types of system-generated discrepancies. This table also lists the scope of the each discrepancy and when the system initiates each.
Table 3-1 Types of System-generated Discrepancies
| Type | Scope | Initiated | Description |
|---|---|---|---|
|
Univariate |
Single response value |
Field-to-field navigation/save action |
A validation error based on the value of a response field. |
|
Multivariate |
One or more response values in one or more CRFs |
Validation |
A sponsor-defined, system-executed validation procedure error based on the values of one or more response fields, across one or more CRFs. |
|
Indicator Question |
Indicator question group |
Save action |
A system error based on incongruity between an indicator question and the presence/absence of data in the remaining question group fields. |
The system generates, or raises, a data discrepancy based on the value of one or more response fields. It may also use derived fields that are based on the value of fields collected through data entry. The system alerts you to the presence of a discrepancy at different times, depending on the type of discrepancy that is generated.
Note that a system-generated discrepancy must be associated with a response field, not the CRF or CRF header fields that collect information about the CRF. When you are recording data in these fields, the system prevents you from recording an invalid value in a these fields, therefore, discrepancies are not necessary.
The system generates a discrepancy based on a difference between the response data in a CRF and some criteria specified in the study. The purpose of the criteria may differ, for example, the goal of certain question definitions is to guard against typographic errors, while a validation procedure may identify combinations of data across CRFs between seemingly unrelated data, such as age, weight, and blood pressure. However, the goal of setting discrepancy criteria in the study design is set triggers that cause the system to initiate discrepancies when certain data is recorded.
A univariate discrepancy is based on the data in a single response field. The system may raise a univariate discrepancy because the value recorded for the response does not meet certain criteria or it may raise the discrepancy because no value is recorded for a response. When the data is recorded in the field, either during data entry or batch data load, the system assesses if the value meets the validation criteria. If the value does not meet a criterion, the system raises a univariate discrepancy.
The system initiates a univariate discrepancy, also called a validation error, based on the data that is recorded in a single response field, either during data entry or batch data load.
As part of the question definition, validation criteria can be specified for a response or a group of responses. The criteria describe what represents valid response values and what does not. During data entry, the system uses the validation criteria to analyze if a recorded response value meets the criteria. If a recorded value does not meet the criteria defined for a response, the system presents the user with a validation error.
Each criterion is based on a single parameter. If a question definition includes more than one validation criteria, each is assigned an order of precedence. When the system evaluates the value you record in a response field, it checks each criterion in turn, in the order specified by the precedence. When the response value violates a criterion, the system does not check any further and it raises a validation error. If a response value violates more than one criterion, the system uses the criterion with the highest precedence to initiate the discrepancy.
Table 3-2 describes the more common parameters that are used to set each criterion.
Table 3-2 Parameters that Define Univariate Discrepancy Criteria
| Parameter | Description | Example of discrepant response |
|---|---|---|
|
Data type |
Specifies the kind of data that can be recorded in the field. This can be either:
|
If the Data type is set to TEXT and the response value is a number. |
|
DVG |
Specifies that the value recorded in the response field is one of the choices in a list of values. |
If the LOV consists of the choices, "Yes" and "No", and the response value is "Not Sure". |
|
Length |
Specifies the maximum number of characters that a response value can use. |
If the Length is set at a maximum of 6 characters and the response value is "Very Good". |
|
Lower Bound |
Specifies that the response value must be above a certain minimum. |
If the Lower Bound is set to "150" and the response value is "127". |
|
Mandatory |
Specifies that the response field must contain data. Note that discrepancies based on this criterion are not generated until the CRF is saved. |
If response field is set to Mandatory and the CRF is saved with no value in the field. |
|
Upper Bound |
Specifies that the response value must be below a maximum. |
If the Upper Bound is set to "60" and the response value is "68". |
Note:
In regard to the Mandatory parameter in Table 3-2, the system cannot evaluate a response for this parameter until you save the CRF. Therefore, the validation error is not raised when you navigate to a different response. On a save action for a CRF with a missing mandatory response:The system displays the validation error before it commits the save action. This allows you to navigate to the mandatory response value and record a value.
During data entry, the system raises the univariate discrepancy when you navigate from the response field or when you initiate a save action. It alerts you to the discrepancy by displaying the Validation Error window. Because the system raises the discrepancy before the response data is committed to the study database, you have the opportunity to review, and, if appropriate, change the response value before it and the discrepancy are saved. The Validation Error window provides information that allows you to evaluate both the recorded value and the reason the system raised the discrepancy.
If the value is inaccurate, you have the option to return to the response field and correct the discrepant value before the discrepancy record is committed to the study database. This is beneficial if the discrepancy is based on a typographical or other kind of data entry error.
If the recorded value is accurate, that is, it matches the source data, you use the validation error window to acknowledge the discrepancy, include any comments that are necessary, and proceed with other data entry tasks. The system saves the discrepancy and assigns it the active status for the current user.
Each time the response is updated, that is, its value is changed, the system re-evaluates the response:
If the value is different, but still discrepant, the system closes the current discrepancy (makes it obsolete) and raises a new discrepancy, even if the new value is discrepant due to the same criterion
If the value is not discrepant, the system makes the discrepancy obsolete and you can proceed with other data entry tasks; the response is considered "clean"
The sequence described in Example 3-1, "Occurrence of a Univariate Discrepancy" illustrates how the system evaluates successive updates to a response field and generates a new univariate discrepancy each time you update the field with a value that violates the validation criteria.
Example 3-1 Occurrence of a Univariate Discrepancy
The question definition may require that the value recorded for given response meets the following criteria:
Data type of "Number"
Lower Bound of "150"
Upper Bound of "200"
It would evaluate the following recorded values accordingly:
If the value recorded is "138", the system raises a discrepancy because it is does not meet the minimum value set by the Lower Bound parameter.
If the value recorded is "JFS", the system raises a discrepancy because the text value is not satisfy the Data Type parameter.
If the value recorded is "214", the system raises a discrepancy because it exceeds the maximum value set by the Upper Bound parameter.
If these three values were recorded in succession, the system would make the discrepancies based on the first and second values obsolete when the field is successively updated.
The recorded data that generates a discrepancy may simply be the result of a typographical error that occurred during data entry. For example, in the first case, above, the user may have meant to type "183," which is a valid entry. Or, the recorded value may have been typed in the wrong response field, as in the second case, in which the patient's initials were recorded. Alternatively, it may be that the recorded data is accurate and the source data does not fall within criteria that the question requires.
A multivariate discrepancy is based on the data in one or more response fields. The system generates this type of discrepancy by assessing one or more response fields in relation to a validation procedure. If the data violates the validation procedure, the system raises a multivariate discrepancy and flags each constituent datapoint that is defined in the validation procedure.
The system initiates a multivariate discrepancy when the data recorded in one or more response fields cause a validation procedure to fail. When a multivariate discrepancy is raised, the system flags each response that is specified in the validation procedure as discrepant.
In contrast to the edit checks associated with univariate discrepancies, the validation procedures that are the basis for multivariate discrepancies run at different times, based on the type of procedure. There are four different actions that run validation procedures:
On a CRF save action.
Select Validate, then Patient from the option list.
Select Validate, then Site from the option list.
Select Validate, then Study from the option list.
When each of these actions occur, the system may generate new multivariate discrepancies.
Example 3-2 Occurrence of a Multivariate Discrepancy
A procedure may be developed that evaluates the value of two responses:
The value of the question "Sex?", which is in the "Demog" CRF.
The value of the question "Systolic BP", which is in the "Vitals" CRF.
When both values are recorded, the system runs the validation procedure, which processes the values:
If "Sex?" is "Female," and
Systolic BP is greater than "135," then the system raises a discrepancy.
Note that this a simple example, given here to illustrate the general concept. In practice, sponsors may develop more complex procedures that evaluate response data on several CRFs and run at various intervals throughout the protocol schedule.
An indicator question discrepancy is based on an incongruity between an indicator question and values recorded in one or more responses in the associated question group. Because it is based on the values of more than one response, it may seem that indicator question discrepancies are a type of multivariate discrepancy. However, in contrast to multivariate, which the system initiates as the result of sponsor-defined validation procedures, indicator questions, like univariate discrepancies, are based on internal processes that are initiated when you save the CRF.
The system initiates an indicator question discrepancy when the response fields associated with an indicator question either:
Contain data when the value of the indicator requires that no data is collected
Do not contain data when the value of the indicator requires that data is collected
The purpose of an indicator question discrepancy is to raise the possibility of a data entry error. Example 3-3, "Occurrence of an Indicator Question Discrepancy", illustrates how the system raises this type of discrepancy.
Example 3-3 Occurrence of an Indicator Question Discrepancy
One section in a CRF is comprised of questions that are specific to female patients. An indicator question, "Male or Female?" is used as a prompt to either record responses or skip the related questions, based on the response value of either "M" or "F".
If the recorded response is "M", the set of related questions must be skipped. If data is recorded in any response field, the system raises an indicator question discrepancy.
If the recorded response if "F", the set of related questions requires responses. If data is not recorded in each such response field, the system raises an indicator question discrepancy for missing data.
If the indicator question value is "M", but all of the related questions are recorded, it may be that value recorded for the indicator question is in error.
Users initiate discrepancies when there is pertinent information that must be noted and communicated to other users. Table 3-3 describes the two types of user-generated discrepancies. This table illustrates several aspects of user-generated discrepancies, with regard to the CRF component with which each is associated and the number of open manual discrepancies that can be associated with that component.
Table 3-3 Types of User-generated Discrepancies
| Type | CRF Component | Number Allowed | Description |
|---|---|---|---|
|
Discrepancy (manual) |
Individual response field |
One |
A comment that is specific to an individual response field. |
|
Section |
CRF section |
Multiple |
A comment that can be generalized for an entire CRF or CRF section, or specific to a particular datapoint that is a component of the CRF section. |
A manual discrepancy is associated with a specific response field in a CRF. A primary reason that users generate a manual discrepancy for a response field is to communicate information to other users about the response value or the condition of the source data.
Only one open manual discrepancy can be associated with a particular response, however, you have the option of updating an existing discrepancy to include new information. When the current discrepancy associated with a particular field is resolved, you can initiate another discrepancy for that field.
A section discrepancy is associated with a CRF section. It is often used as a means of communication, between a site and a CRA, about issues related to the relevant part of a CRF. In contrast to the response field discrepancy, more than one open section discrepancy can be associated with a CRF section. In addition, this type of discrepancy can be set to internal, which can limit the user groups who have access to it. (Refer to "Internal Discrepancies" for more information.)
You initiate a user-generated discrepancy by taking a specific action. You can associate the discrepancy with a single response field or with an entire CRF section. You place focus in the response or section where you want to initiate the discrepancy and you take actions to cause the system to display the appropriate tools that allow you to describe the reason for the discrepancy.
The primary purpose of user-generated discrepancies is to allow users to provide comments and additional information about the question or a CRF section. When you complete the task, the system displays the discrepancy as active for your user role.
Only one open, user-initiated discrepancy can be associated with a response field. If you attempt to initiate a new discrepancy in a response for which a manual discrepancy already exists, the system prompts you update the existing discrepancy. In contrast, more than one open section discrepancy can be associated with a CRF section, therefore, for a section with a pre-existing discrepancy, you have the option to update discrepancy or add a new discrepancy.
This section describes the terms that are used to classify discrepancies and the actions that are used to process them. This section is comprised of the following topics:
A discrepancy is either in the current or obsolete state. Within the current state, there are statuses that further describe the disposition of the discrepancy. All user interaction with a discrepancy occurs while it is current. Only the system can change a discrepancy from the current to the obsolete state. Once it is obsolete, no further action on the discrepancy, either by users or the system, is permitted.
When a discrepancy is raised, either by a user or the system, it is, by definition, current. It remains current until the system takes action on it that renders it obsolete. Each discrepancy in the current state is assigned a discrepancy status, which further describes its disposition (Refer to "Current Discrepancy Statuses" for further information).
While it is current, users and the system can take action on it. As users take different actions on a discrepancy, it may remain current but its discrepancy status may change. However, only the system can take action on a discrepancy to change it to the obsolete state.
The purpose of the obsolete state is to preserve a record of the discrepancy and to provide verification that the discrepancy has been processed. Unlike current discrepancies, users and/or the system are not permitted to take action on obsolete discrepancies. The only user interaction that is permitted is review of the discrepancy history.
Each current discrepancy is described in terms of a discrepancy status. This is a designation that allows you to track a discrepancy based on the user group that is currently responsible for managing the discrepancy.
Whatever status an open discrepancy appears to you, it is the same for all other members of your user group. When the status changes, it changes for the entire user group. It is only when the discrepancy is actionable that the status is based on user role. In contrast, when a discrepancy is closed, its status is the same for all users.
The discrepancy status of an open discrepancy specifies whether you (and other members of your user group) can take action on the discrepancy.
Two discrepancy statuses can be associated with an open discrepancy:
Active — indicates that you can take action on the discrepancy
Other — indicates that it is directed to a different user role
RDC Classic uses the color red to indicate that a discrepancy is active for you. It uses the color yellow to indicate that the discrepancy is open, but is not actionable by you (or other members of your user group).
The closed discrepancy status indicates that a user has resolved the discrepancy. A user resolves a discrepancy by selecting a discrepancy action that changes the discrepancy from open to closed. When a user closes a discrepancy, the system requires that the user specify a resolution reason, which is saved as part of the discrepancy record.
A discrepancy proceeds through discrepancy management by way of discrepancy actions. Certain actions, such as updating the comments in a discrepancy, help to clarify the cause of the discrepancy, with the aim of enhancing communication among users and ultimately closing the discrepancy. Other actions, such as routing, change the status of the discrepancy in order to alert other user groups and solicit input in the management of the discrepancy.
There are three actions that you can take on a discrepancy that change the discrepancy status:
Initiate — causes the discrepancy to become current and active for your user group
Route — change the status of an open discrepancy so that it is active for a different user group
Resolve — change the status of the discrepancy to closed
In addition, there are other actions you can take on a discrepancy that allow discrepancy management to proceed but do not alter the discrepancy status. These include:
Evaluate, or receive
Respond
Update
Review
Users can take the same actions on manual discrepancies as they can on data discrepancies. Changes to response data do not alter the status of user-generated discrepancies.
The system also takes action on discrepancies, with these limits:
The system only initiates a discrepancy based on data in one or more response fields. For example, the initiation of a system-generated section discrepancy is not permitted.
When the system initiates a data discrepancy, it is assigned the active status for one or more user group and the other status for all other user groups. Generally, the discrepancy is set to active for the user group responsible for data entry tasks.
The system does not route discrepancies.
There are specific conditions under which the system makes a discrepancy obsolete.
The actions that the system can take on a discrepancy are:
Initiate
Obsolete
The only situation in which the system takes action on a manual discrepancy is when the response or the section with which the discrepancy is associated is deleted. For example, if the CRF is marked blank, the system changes all response and section-level manual discrepancies to obsolete.
A discrepancy can be initiated either by a user or the system. When a discrepancy is initiated, it is set to the active discrepancy status for at least one user group and it is set to the other status for the remaining user groups.
The initiation of a system-generated discrepancy is based on recorded data and the question definitions and validation procedures that are defined in the protocol. Users have no control over the initiation of system-generated discrepancies – it is based strictly on the data that is recorded in the CRFs.
Users can initiate a discrepancy for any datapoint or CRF section in a CRF, within certain limitations.
The privileges assigned to the user name must permit initiation and update of discrepancies.
Only one open user-generated discrepancy can be associated with a response field.
The relevant CRF must be updateable, that is, it cannot be locked.
The basic procedure for initiating a manual discrepancy entails placing focus in a response field or CRF section and selecting the appropriate commands to initiate the discrepancy. When this occurs, the system displays a window that allows the user to record pertinent information about the discrepancy, including the error reason, which states the issue that is the basis for the discrepancy, and comments that provide ancillary information about the discrepancy. In addition, you also have the capability to take immediate action on the discrepancy.
The purpose of routing is to alert users in a different user group to the presence of the discrepancy. Routing actions are only available to users, the system does not route discrepancies.
In order to route a discrepancy, the user selects from a set of discrepancy actions that the system presents. This set of actions is sponsor-defined and is specific to the current user's role. The set includes both routing and resolution actions.
Example 3-4 Typical Routing Action
If an investigator initiates a discrepancy for a response field in order to send a comment to the CRA, the investigator would use an action such as, "Send to CRA". This would change the status of the discrepancy for the CRA to active, which permits all users in the CRA role to then take action on the discrepancy. The CRA would then review the discrepancy, add any relevant comments, and choose the "Send to Investigator" action.
Note that the "Send to CRA" action is not available to the CRA role. Likewise, the "Send to Investigator" action is not available to the investigator role.
Internal discrepancies are a special case of user-initiated discrepancy that allow a user to route the discrepancy to a different user group and cause the discrepancy to be hidden from other user groups. In order to facilitate this functionality, the sponsor must define a type of routing action that renders the discrepancy viewable to certain user roles and hidden to other roles. For user groups for which the discrepancy is hidden, an internal discrepancy, for all intents, does not exist. For user groups for which the discrepancy is viewable, it can either be in the active or other status and is generally indistinguishable from all other discrepancies. A typical use of internal discrepancies is to facilitate a private means of communication between specific user roles.
If an internal discrepancy is available to your user group, you can take the same actions on it as you can with any other discrepancy: you can route it to another user role, and you can resolve it. In the GUI, an internal discrepancy appears the same as any other.
Example 3-5 Internal Discrepancy
One scenario for the use of an internal discrepancy is as a means of private correspondence between sponsor personnel.
For example, a CRA generates a section discrepancy. Initially, the discrepancy is assigned a status of active for the CRA and other for all other user roles.
If the CRA then routes the discrepancy, for example, by using a discrepancy action, "Route to Data Manager – Internal," the discrepancy status for each role is:
INV (Investigator) – N/A; users in the INV role are no longer able to view the discrepancy
SITE (Site Coordinator) – N/A; users in the SITE role are no longer able to view the discrepancy
CRA – Other; because a CRA user routed the discrepancy to another user role, the discrepancy is now assigned a status of other for all CRAs
DM (Data Manager) – Active; because the discrepancy was routed to this role, it is now assigned a status of active for all DMs.
A full sequence is outlined in Table 3-4, "Example of Internal Discrepancy Routing" in which an Investigator initiates a section discrepancy and routes it to a CRA, who then routes it to the DM role as internal.
Table 3-4 Example of Internal Discrepancy Routing
| Action | INV | SITE | CRA | DM |
|---|---|---|---|---|
|
CRA initiates a section discrepancy |
Active |
Other |
Other |
Other |
|
CRA reviews and routes to DM as internal (Send to DM – internal) |
N/A |
N/A |
Other |
Active |
|
DM reviews/responds and routes to CRA as internal (Send to CRA - internal) |
N/A |
N/A |
Active |
Other |
|
CRA reviews and chooses to close the discrepancy as resolved (Close – Resolved) |
Closed |
Closed |
Closed |
Closed |
When a user closes a discrepancy, it is termed a "resolution action." When you initiate a resolution action, the system requires that you include a resolution reason, which is chosen from a sponsor-defined list and describes why the user closed the discrepancy. You also have the option to include a explanatory comment with the resolution reason.
A user may resolve a manual discrepancy after the issue that was the basis of the discrepancy has been discussed and/or clarified among the interested parties. At that point, a user would review the discrepancy and then choose a resolution action, for example, "Closed – Issue Resolved."
A user may resolve a data discrepancy after the accuracy of the recorded value has been checked against the source data. For example, if a recorded value exceed the criteria for a question and raises a validation error, a user may choose to resolve the discrepancy after ensuring the value in the CRF matches the source data.
A user can close any type of discrepancy, however, even after the user has resolved the discrepancy, the system may change its status to obsolete.
The system closes discrepancies based on the following:
The data upon which the discrepancy is based is updated such that the discrepancy no longer exists
the responses to which the discrepancy is associated are deleted (this also applies to manual discrepancies)
The validation procedure that caused the error is retired.
Although a user cannot take further action on a closed discrepancy, the system can change the status of a closed, resolved discrepancy to obsolete based on the criteria above.
Once a discrepancy is initiated, which means that it is in the current state, the system can take no other action on it, except to make it obsolete. This includes discrepancies that are open and closed. When a discrepancy is in the closed state, users cannot take further action on it. However, the system can alter the status of user-closed discrepancy to obsolete.
The obsolete status is assigned to a discrepancy under the following circumstances:
The value of the data that caused the system to initiate the discrepancy is updated so that it is no longer discrepant.
The discrepancy is a constituent of a CRF that is deleted.
The validation procedure that raised the discrepancy is retired, that is, it is either removed from the protocol or it is replaced by another procedure.
The discrepancy is associated with repeating question that is deleted.
This section provides a synopsis of the classification, requirements, and capabilities of discrepancies in RDC Classic.
There are two types of discrepancy, based on where it originates:
System-generated (for example, a validation error that results in a univariate discrepancy)
User-generated (for example, a section discrepancy that a user initiates)
Discrepancies can be associated with either a:
Datapoint/response field(s) – either user- or system-generated
CRF section – user-generated only
The system can take two types of action on a discrepancy:
Initiate
Obsolete
A user can take three types of action on a discrepancy:
Initiate
Route
Resolve
A discrepancy can be in one of two states:
Current
Obsolete
An open discrepancy can be in one of two statuses:
Active
Other
A closed discrepancy can be one of two types:
System-closed (obsolete)
Resolved (user-closed)
No further action can be taken on an obsolete discrepancy.
A CRF is termed clean, if either of these conditions are present:
No discrepancy has been associated with it
or
If any user-generated discrepancy associated with it has been resolved and/or any system-generated discrepancy associated with it has been closed
This section provides overview information about discrepancy management. It uses the information presented in "Discrepancies in RDC Classic".
As you enter response data and attempt to navigate to another field, RDC Classic saves the data and, in certain circumstances, compares it to criteria that the sponsor has defined for the question. When the data is outside the criteria, RDC Classic notifies you of a discrepancy by displaying the Validation Failure Window and maintains focus in the field. The purpose of this functionality is to reduce data entry errors by allowing you to analyze and compare the source data document to the value that you entered in the response field.
The Validation Failure Window provides basic information that describes why the data is discrepant. It also provides a means for you acknowledge the discrepant data, include a comment with the discrepancy, and take action on the discrepancy.
Although you have the opportunity to change the data before RDC Classic logs a discrepancy,you cannot navigate to another data point before you resolve the status of the current data point.
If you review the source data and, based on that, change the value of the data such that it is no longer discrepant, the system permits you to navigate to other response fields and continue with initial data entry.
If you review the source data and change the value of the data such that it is still discrepant, the system will display the Validation Failure window based on the new data value. In this case, you must process the discrepancy before the system allows you to proceed with data entry.
If the data in response field matches the source data and it is discrepant, you must process the discrepancy before the system allows you to proceed with data entry.
Therefore, when the system presents the Univariate Validation Failure window, you have the following options:
Correct the response data based on a review of the source data and proceed
Acknowledge the discrepancy and proceed
Acknowledge the discrepancy and route it to another role
The general sequence required to initiate a manual discrepancy is:
Place focus in the response field with which you want to associate the discrepancy.
Select Insert, then Discrepancy (manual) from the option list to open the Comment for Question Window.
In the Comment for Question window, provide information that describes why you are initiating the discrepancy.
Close the discrepancy window.
The process to initiate a section discrepancy is similar. When you select Insert, then Section Discrepancy from the option list, the system opens a discrepancy for the section that contains the response field that is in focus.
The Discrepancy task tab provides a single location to review all discrepancies that are associated with the CRF that is in focus. The List of Discrepancies tab provides a prioritized display of all discrepancies and allows you to modify the Error Message and Comment text, as appropriate, directly in the tab. The Individual Discrepancy tab is particularly useful when you review multivariate discrepancies.
You can take action on a discrepancy from either sub-tab.
When the system presents the Validation Failure window, the Message section displays the system-generated reason that the data value is discrepant. The response value is included in the reason. This allows you to compare the value that you typed in the response field to the source data value. If the two values do not match, use this procedure to navigate back to the response field and correct the value you typed. This procedure avoids the creation of a system-generated discrepancy.
In the Validation Failure window, click the Cancel button. The window closes and the system places focus in the discrepant response field.
In the response field, edit the value so that it matches the source data.
Navigate to another response field or save the CRF.
If the new value is valid, RDC Classic permits the navigation or the explicit save.
If the new value is discrepant, the Validation Failure window displays with the new value included in the Message text box.
If the Validation Failure window displays again, which may indicate that the source data value has caused the validation failure, review the workflow in the Procedures section to assess the method you should use to process the discrepancy.
Use this procedure if you want to acknowledge the Validation Failure window and,optionally, include a comment with that the system saves with the discrepancy record.
In the Validation Failure window, review the Message text box and ensure that it includes information relevant to the discrepancy. If necessary you can edit the contents of the text box, either directly within the text box or in a separate editor.
Use the Comments text box or the Internal Comments button to include an comment with the discrepancy.
When the contents of the Message and the Comments text boxes are satisfactory,click the OK button to save the discrepancy record and close the Validation Failure window.
This procedure describes the steps to acknowledge the discrepancy and route it to a different user group (that is, make it Active for another role).
Note:
The actions that are available are based on your user role.However, your system administrator is responsible for defining the entire set of actions for the study.In the Validation Failure window, review the Message text box and ensure that it includes information relevant to the discrepancy. If necessary you can edit the contents of the text box, either directly within the text box or in a separate editor.
Use the Comments text box or the Internal Comments button to include an comment with the discrepancy.
In the Action drop-down list, select a routing action. The Internal Comment window displays.
In the Internal Comment window, type an optional comment that you want to save with the discrepancy.
In the Internal Comment window, click the OK button to save the comment and close the window.
In the Validation Failure window, click the OK button to save the discrepancy and the discrepancy action. The window closes.
This procedure describes the steps to acknowledge and resolve the discrepancy.
Note:
The actions that are available are based on your user role. However, your system administrator is responsible for defining the entire set of actions for the study.In the Validation Failure window, review the Message text box and ensure that it includes information relevant to the discrepancy. If necessary you can edit the contents of the text box, either directly within the text box or in a separate editor.
To edit within the text box, place the cursor focus at an appropriate point in the message text.
To edit in a separate editor, click the Comment button adjacent to text box.
To include an optional comment with the discrepancy:
Place cursor focus in the Comments text box, or
Click the Internal Comments button adjacent to the text box
In the Action drop-down list, select a resolution action. The Resolution Reason window displays.
In the Resolution Reason window:
Select a resolution reason from the Resolution drop-down list.
Type an optional comment in the Comment text box that you want to save with the discrepancy.
In the Resolution Reason window, click the Save button to save the resolution reason and comment, if present, and close the window.
In the Validation Failure window, click the OK button to close the window and save the discrepancy and the discrepancy action.
|
 Copyright © 2000, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
