My Oracle Support Banner

Enabling Partial Source Data Verification (PSDV) in an Existing RDC Study (Doc ID 1945698.1)

Last updated on MAY 31, 2019

Applies to:

Oracle Clinical
Oracle Clinical Remote Data Capture Option
Information in this document applies to any platform.

Purpose

Oracle® Clinical Remote Data Capture Enabling Partial Source Data Verification (PSDV) in an Existing RDC Study

 

Oracle® Clinical Remote Data Capture Enabling Partial Source Data Verification (PSDV) in an Existing RDC Study
Release 5.1 and Above
My Oracle Support Article ID 1945698.1
 

 

Oracle® Clinical Remote Data Capture

Enabling Partial Source Data Verification (PSDV) in an Existing RDC Study

Release 5.1 and Above

My Oracle Support Article ID 1945698.1

July 2016

 

Frequently Asked Questions

Oracle Clinical Remote Data Capture (RDC) supports risk-based partial source data verification beginning in Release 5.1.

How does Partial Source Data Verification (PSDV) work in RDC?

Can I upgrade to RDC 5.1 and start using PSDV for existing live studies?

What if I don't want to enable PSDV for ongoing studies?

Can I have separate PSDV plans for different sites?

Will enabling PSDV impact performance?

Why is the Pending Patient Updates job needed?

Should I always publish both a patient plan and a CRF plan?

Can I feed revisions to the plan from an external statistical analysis system?

Where do I find all the documentation for Partial Source Data Verification support in Release 5.1?

How does Partial Source Data Verification (PSDV) work in RDC?

There are two parts to PSDV in RDC:

  • Critical CRF Plan: Marking certain CRFs as requiring verification every time they are collected in a study.

  • Patient Plan: Defining a percentage of patients randomly assigned for verification of 100% of their records.

Only users with special privileges can see which data must be source-verified and record the source data verification progress.

Can I upgrade to RDC 5.1 and start using PSDV for existing live studies?

Yes.

To start a critical CRF plan:

  1. Select the SDV? check box for a Study DCI to make the corresponding CRF require SDV for all patients.

  2. Create and publish the SDV plan.

To start a patient SDV plan:

  1. Make some or all patients eligible for PSDV. Enter a date for SDV eligibility for patient positions manually or using batch data load. (For new studies you can also use a procedure that is triggered by data entry in a particular CRF.)

  2. Create SDV default values for the initial number of patients and percentage of patients requiring SDV. Either publish patient SDV plans for all sites from Oracle Clinical or for specific sites from RDC. Adjust the values for each site as needed In RDC.

  3. Schedule the Pending Patient Updates job, which runs across all studies.

You can do these steps in any order, but the algorithm that randomly assigns some patients to SDV does not run until all are done and the Pending Patient Updates job runs. The job will take some time the first time it runs in an ongoing study because it is processing many patients. See Will enabling PSDV impact performance?.

What if I don't want to enable PSDV for ongoing studies?

Do nothing and your studies continue to work the way they did before the upgrade.

Can I have separate PSDV plans for different sites?

Yes. You can create patient and/or critical CRF SDV plan versions for individual sites after initial publication of the plans based on study-level default values.

Will enabling PSDV impact performance?

The first time the Pending Patient Updates job runs in an ongoing study may take a long time because it is processing many patients. To minimize this:

  • The first time you run Pending Patient Updates in the database, schedule a one-time execution during the least busy time.

  • After the initial run, schedule Pending Patient Updates to run frequently.

  • For subsequent studies, publish the patient SDV plan for each site separately in RDC. The next time Pending Patient Updates runs it will process all patients from that site. Testing showed the time to publish plans for up to 2000 patients was under 20 seconds.

After the initial processing and in new studies, testing has shown an insignificant impact on RDC performance.

Why is the Pending Patient Updates job needed?

Patient eligibility updates may be deferred because another process has locked the Patient Positions table. These updates are maintained in a queue and committed by the first Pending Patient Update job to run after the lock is released.

Should I always publish both a patient plan and a CRF plan?

If you need one type of plan but not the other, you may need to publish an "empty" plan for the unneeded type:

  • If you are publishing a patient SDV plan—some patients require 100% SDV—always publish a critical forms SDV plan too. If there are no critical forms that require SDV for all patients, publish an "empty" forms plan in which no forms are selected. This way, an RDC search for CRFs requiring SDV retrieves only the CRFs entered for patients requiring 100% SDV. Without any critical forms plan, the system retrieves all CRFs for all patients.

  • If you are publishing a critical forms SDV plan—some CRFs require 100% SDV—but no patients require 100% verification, you may or may not want to publish an "empty" patient plan.

    • If you publish an empty patient plan—in which both the initial patient count and the auto-selection rate are zero and no patients are made eligible—RDC Search panes include the option to search for Patients requiring 100% SDV, although there are none. This maintains consistency in the RDC Search pane from one site to the next.

    • If you do not publish any patient plan, RDC users will not have the option to search for patients requiring 100% SDV at any study site, but such a search would never retrieve any records anyway.

  • For sites requiring 100% SDV (all CRFs for all patients), publish a patient SDV plan that specifies an auto-selection rate of 100%. There is no need to publish an accompanying forms SDV plan in this case.

Can I feed revisions to the plan from an external statistical analysis system?

This is possible through the PSDV web services. You can get payloads with information about the new initial patient count and automatic selection rates coming from an external statistical analysis system. The web service creates a new plan version with the values and can publish the new plan too if it's set up that way.

See the Oracle Clinical API Guide for information on PSDV web services at http://docs.oracle.com/cd/E52785_01/doc.51/e53565/web_services.htm#CHDJAGHB.

Where do I find all the documentation for Partial Source Data Verification support in Release 5.1?

Start with the introductory section in Oracle Clinical Creating a Study at https://docs.oracle.com/cd/E52785_01/doc.51/e52787/plan.htm#CACBEJAC. It lists all related documentation.

Download all Oracle Clinical and Remote Data Capture user manuals here: http://www.oracle.com/technetwork/documentation/hsgbu-clinical-407519.html

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.


Enabling Partial Source Data Verification (PSDV) in an Existing RDC Study, Release 5.1 and Above

My Oracle Support Article ID 1945698.1

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

 

 

Scope

 

Details

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Purpose
 Oracle® Clinical Remote Data Capture
 Frequently Asked Questions
 How does Partial Source Data Verification (PSDV) work in RDC?
 Can I upgrade to RDC 5.1 and start using PSDV for existing live studies?
 What if I don't want to enable PSDV for ongoing studies?
 Can I have separate PSDV plans for different sites?
 Will enabling PSDV impact performance?
 Why is the Pending Patient Updates job needed?
 Should I always publish both a patient plan and a CRF plan?
 Can I feed revisions to the plan from an external statistical analysis system?
 Where do I find all the documentation for Partial Source Data Verification support in Release 5.1?
 Documentation Accessibility
Scope
Details

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.