discrepancy management
Post on 22-Oct-2014
280 Views
Preview:
TRANSCRIPT
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.
top related