DISCREPANCY MANAGEMENT

OVERVIEW

Clinical Data Coordinators have to play a vital role in clinical studies. There main works lies in data Accuracy, meeting the study timelines and maintain quality as per the ICH GCP compliance

The system creates a discrepancy record in the discrepancy database, either during manual data entry or update, batch data load, or batch validation, if the response to a question is invalid.

WHAT IS DISCREPANCY?

Any Data which does not match and expected value this does not necessarily mean the data is wrong, it means it is not consistent with the expected data

Discrepancy Management is the process of reviewing and resolving data inconsistencies identified from data entry and batch loaded data

The discrepancy Management system is oracle clinical component used to deal with discrepancies

DISCREPANCY MANAGEMENT WORKFLOW

TYPE OF DISCREPANCIES

Univariate Multivariate Indicator Manual Manual Data Point

UNIVARIATE

During Data entry or Batch data Load, Oracle Clinical Checks data entered as a response to question against the definition of the question, and generates a discrepancy if the response does not meet the definition specifications such as wrong data type or length, response not in the discreet value group, incorrect partial dates.

MULTIVARIATE DISCREPANCY

When validation procedure finds data which is violates it’s programmed rules, a multivariate discrepancy created

Example: The Value Provide for Hg is greater than the normal reference.

MANUAL DISCREPANCY

If there is a problem transcribing data from a CRF, you can enter a manual discrepancy.

Manual Data Point. If there is a problem with the CRF, such as illegibility, you can enter a manual discrepancy either during data entry, or directly into the discrepancy database.

INDICATOR DISCREPANCY

The response to an indicator Question determines which set of the remaining Questions require responses. For example, if the response to the indicator Question “Do you smoke?” is Yes, then the question “How often?” must also be collected. If the response to “Do you smoke?” is No, then “How often?” must not be collected. If a follow-up question is either not collected when it should be, or collected when it should not be, Oracle Clinical creates an indicator discrepancy during batch validation.

TYPE OF UNIVARIATE DISCREPANCY Data type:- The response does not match the

question’s data type DVG:- The value entered does not match the

DVG values DVG Subset::- The value is entered in the base

DVG but not the subset Mandatory:- No response has been entered for

a question which has been defined as mandatory

Length:- The response to a question is longer than the length specified in the question definition

TYPE OF UNIVARIATE DISCREPANCY

Partial Date:- The response to a date/time question is incomplete

Lower Bound / Upper bound:- The number or the date/time entered is smaller / larger than that specified in the question definition

Thesaurus:- The entire value does not match the Thesaurus DVG value

Missing PT:- The response to a questions linked to TMS does not have a match to one or more of the preferred terms

MULTIPLE UNIVARIATE ERRORS

The system creates only one Univariate Discrepancy at a time per question, resolving one error may allow the other to surface

Each type of question is checked in the particular order:- Character:- Mandatory, length, DVG, Thesaurus, Missing_PT

Numeric:- Mandatory, Data type, Length, Precision, Upper bound/ Lower bound

Date/Time:- Mandatory, Data Type, Partial date, Upper bound / Lower bound

CRF DESIGNING

SYSTEM STATUS

Discrepancies are associated with three types of status codes: system, review, and resolution.

The system status code is CURRENT as long as the data is discrepant. When the discrepancy is resolved, the system automatically updates the system status to OBSOLETE.

REVIEW STATUS

Oracle Clinical ships three default review status codes :

- Unreviewed - Closed - Irresolvable

UNREVIEWED

Oracle Clinical assigns an initial review status value of unreviewed to each new discrepancy. As discrepancies progress into different stages of the review process, a user or the system updates the review status.

CLOSED

Once you’ve resolved a discrepancy, the system sets its review status to Closed and its system status to obsolete. When a discrepancy is closed, it is removed from its DCF(if any) and no longer appears as current in discrepancy reports

IRRESOLVABLE

Irresolvable. If you set the discrepancy review status to irresolvable, you must also set the resolution status.

UNREVIEWED and CLOSED are system review statuses Custom review statuses are DM REVIEW, CRA REVIEW and

INV REVIEW etc. These are statuses used to indicate who should

RESOLVED and IRRESOLVABLE are statuses assigned by users to indicate that a discrepancy has been closed manually

RESOLUTION STATUS

Describes how the discrepancy was resolved.

For example, CRA ACTION, QA ACTION, or NO ACTION REQD.

System Assigned RESOLUTION STATUSES

DATA CHANGE The data that caused the discrepancy has changed

DATA REMOVED The data that caused the discrepancy has been deleted

RESOLUTIONS STATUS

DATA REMOVED The data that caused the discrepancy has been deleted

DVG or DVG Subset The DVG or DVG subset involved with the discrepancy was changed

KEY CHANGE Header data change so that discrepancy no longer exists

VALID.CHANGE or VALID.RETIRED The validation procedure or the question attributes that created the discrepancy was changed or the procedure was retired

VIEWING DISCREPANCIES IN OC

Production mode data is available through Conduct→Data Validation → discrepancy database

For test-mode data, Navigate to Definition → test a study → Discrepancy Database

Choose your study and choose the “DM Master Profile” and Press Use

DISCREPANCY HISTORY

Oracle Clinical generates a discrepancy history record whenever there is a change in the discrepancy’s: Review status Resolution status Internal comment text Resolution text Either or both flex fields

To view the history of a discrepancy, select the discrepancy in the Maintain Discrepancy Database window and click the View History button.

DISCREPANCY HISTORY

The Discrepancy History window opens. The history record includes all of a discrepancy’s change details, as well as the changes’ owners and timestamps.

Click the icon to the right of the Internal Comments field to read the internal comments.

The Discrepancy History window is display-only. Click the Back button to return to the Maintain Discrepancy Database window.

MISSING AND OVERDUE DCMS Missing: The DCM was not received at the expected visit,

but other DCMs were received during that visit or subsequent visits.

Overdue: The DCM was not received at the expected visit and 30 or more days have passed since the expected date for that visit; also, no other DCMs have been received for that visit or later visits.

Missing & Overdue: The DCM is missing and 30 or more days have passed since the expected date for that visit.

Missing DCMs can be marked as Not Expected if appropriate.

DCF Data Clarification Forms (DCFs) are used

to organize discrepancies into group and send them for Clarification

DCF CREATION

DCF Reports can be created directly from the discrepancy Management interface. Press the Multi-view icon (Upper right) and use CTRL + Click to select a discrepancy for the DCF

Select the Create DCF radio button and Press OK.

The dialogue for the DCF properties open as show below. Press OK.

The 1 DCFs Created dialogue should appear. Press Ok.

DCF STATUS The DCF has a status that is used to track the

progress of the DCF The statuses are controlled in the code list DCF

STATUS CODES The preloaded statuses are CREATED (REQUIRED) DRAFT FINAL READY SENT (REQUIRED) MISSING INCOMPLETE

DCF STATUS

PART RECEIVED RECEIVED REVIEWED VERIFIED CLOSED (REQUIRED)

LOCKING Locking is the process of preventing changes to

individual RDCIs or RDCMs.

Once response data contained in RDCIs and their RDCMs has been reviewed and cleaned, you may want to ensure that no one makes changes to it unless explicitly authorized.

If you have the correct security role, you can secure data at the level of the study, investigator, patient, RDCI, or RDCM

and prevent further modification.

LOCKING To lock a RDCM, you specify

Investigator ,or Patient ,or DCI name ,or Clinical Planned Event ,or Accessible date to be locked.

FREEZING Freezing is the process of preventing changes or

additions to data at the study, investigator, and patient levels.

When you freeze a patient you prevent any changes to data for that

patient. no new RDCIs or RDCMs can be logged or

entered for that patient, and all existing RDCIs and RDCMs for the patient

are locked. When you freeze an investigator

all patients for that investigator are also frozen. locks all RDCIs and RDCMs for all patients

associated with that investigator.

FREEZING

When you freeze a study the system locks all RDCIs and

RDCMs in that study not already locked. also freezes investigators and

patients for the study.

The study-level lock excludes the study from any validation processing

You can subsequently unfreeze patients, investigators, and studies.

UNFREEZING

When you unfreeze a study you can add new data or patients

without restriction,

When you unfreeze a study, investigator, site, or patient the RDCIs and RDCMs remains

locked.