Since the introduction of the Electronic Data Capture (EDC) in clinical trials where data is entered directly into the electronic system, it is estimated that the errors (e.g. transcription error) have been reduced by 70% [ Clinical Data Interchange Standards Consortium – Electronic Source Data Interchange 2005].

The Data Management Plan (DMP) defines the validation test to be performed to ensure data entered into the clinical database is complete, correct, allowable, valid and consistent.

Within the DMP, we find the Data Validation Plan. Some companies call it ‘DVS’ others ‘DVP’.  The Good practices for computerized systems in regulated GxP environments defines validation as a system that assures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of software and system development, its implementation, qualification and acceptance, operation, modification, qualification, maintenance, and retirement.

As an {EDC} Developer or Clinical Programmer, you will be asked to:

  • Develop test scripts and execution logs for User Acceptance Testing (UAT).
  • Coordinate of UAT of eCRF build with clinical ops team members and data management and validating documents, included but not limited to: edit check document, issue logs, UAT summary report and preparation and testing of test cases.

Remember not every EDC system is alike. Some systems allow you to perform testing on the edit checks programmed; others allow you to enter test data on a separate instance than production (PROD).

Data Validation and UAT Module.png

For example, some EDC systems facilitate re-usability:

  1. There is a built-in test section for each study – where data can be entered and are stored completely separate from production data. This allows you to keep the test data for as long as needed to serve as proof of testing.
  2. The copy function allows for a library of existing checks (together with their associated CRF pages) to be copied into a new study. If there are no changes to the standard checks or pages then reference can be made back to the original set of test data in a standards study, thus reducing the study level overhead.
  3. The fact that many of the required checks (missing data, range checks, partial dates etc.) do not require the programming of an edit check at all. Each of these and many others are already there as part of the question definition itself and therefore do not need any additional testing or documentation for each study.

If you have not documented, you have not done it-FDA

The “ideal world” scenario would be to reduce the actual edit check testing by the system generating a more “human readable” format of the edit checks. The testers that way would not have to test each boundary conditions of the edit checks once the system is validated. All they would have to do is inspect the “human readable” edit checks vs the alerts and would also be easy for the clients to read and sign off.

You can leverage the EDC systems audit trail under certain conditions. First of all – the system you are testing with must be validated in itself. Some EDC products are only ‘validated’ once a study is built on top of them – they are effectively further developed as part of a study implementation process – in this situation, I would doubt you could safely use the audit trail.

Secondly, you need to come up with a mechanism whereby you can assure that each edit check has been specifically tested – traceability.

Finally, you need to secure the test evidence. The test data inside the EDC tool must be retained for as long as the archive as part of the evidence of testing.

The worst methods in my view are paper / screenshot based. They take too long, and are largely non-reusable. My past experience has been creating test cases using MS Word then performing each step as per test case and take a screenshot, where indicated. Then attached to the final documentation and validation summary. This obviously a manual and tedious process. Some companies create test cases using HPQC or similar tool. This is a bit more automated and traceable yet, it is still prone for errors. It is better than documenting using MS Word or Excel but it is still a manual process.

Re-usability is what it is all about, but, you need to ensure you have methods for assuring the test evidence produced for edit checks you are reusing is usable as part of the re-use exercise.

Edit Check Design, Development and Testing is the largest part of any typical EDC implementation. Applying methods to maximize quality and minimize time spent is one of the areas I have spent considerable time on over the last couple of years.

For additional tips on writing effective edit checks please go here -Effective edit checks eCRFs.

To hire me for services, you may contact me via Contact Me OR Join me on LinkedIn

Source images: provided courtesy of Google images.

-FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Advertisements