Tag Archives: custom edit checks

How to document the testing done on the edit checks?

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.

“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.”

How to write query texts – 6 template sentences

How to write queries unambiguously expressing what is asked for? Using short, polite sentences? Objectively explaining the underlying inconsistency?

First of all my general guidelines.

My preference is to use no more capitals then needed. Capitals in the middle of a query text, e.g. for CRF fields or for tick box options, could distract from getting the actual question asked. E.g. compare the same query texts, with and without extra capitals. Please verify stop date. (Ensure that stop date is after or at start date and that stop date is not a future date.) Please verify Stop date. (Ensure that Stop date is after or at Start date AND that Stop date is not a future date.)

Referring to CRF fields as they are shown on the CRF. To easily find the involved field(s).

I prefer to leave any ‘the’ before a CRF field referral out of the query text. For more to-the-point query texts. E.g. compare the same query texts, with and without ‘the’ before data fields. Please verify stop date. (Ensure that stop date is after or at start date and that stop date is not a future date.) Please verify the stop date. (Ensure that the stop date is after or at the start date and that the stop date is not a future date.)

Consistency in phrasing a query text can help to quickly write query texts or pre-program query texts in a structured, familiar way. That’s the thought behind the following 6 template sentences for query texts. Which you can use to help you write or program your queries.

The six ‘template’ sentences for query texts:

Please provide…

For asking the study site people to provide required data from patient care recordings. Examples: Please provide date of visit. Please provide date of blood specimen collection. Please provide platelet count. Please provide % plasma cells bone marrow aspirate. Please provide calcium result.

Please complete… For asking the study site people to complete required data as required by the study CRF design. (Not necessarily required for patient care). Examples: Please complete centre number. Please complete subject number. Other frequency is specified, please complete frequency drop-down list accordingly.

Please verify…

For asking the study site people to check date and time fields fulfilling expected timelines. Or for asking the study site people to check field formats. Examples: Please verify start date. (Ensure that start date is before date of visit.) Please verify stop date. (Ensure that stop date is after or at start date and that stop date is not a future date.) Please verify date of blood specimen collection. (Ensure that date of blood specimen collection is before or equal to date of visit and after date of previous visit.) Please verify date last pregnancy test performed. Please verify date of informed consent. (Ensure date of informed consent is equal to date of screening or prior to date of screening.) Please verify date as DDMMYYY.

…., please correct.

For asking the study site people to correct a data recording inconsistent with another data recording. Example: Visit number should be greater than 2, please correct.

…., please tick…

For asking the study site people to complete required tick boxes. Examples: Gender, please tick male or female. Pregnancy test result, please tick negative or positive. Any new adverse events or changes in adverse events since the previous visit, please tick yes or no. Laboratory assessment performed since the previous visit, please tick yes or no. LDH, please tick normal, abnormal or not done.

Please specify…

For asking the study site people to specify the previous data recording. Examples: Please specify other dose. Please specify other frequency. Please specify other method used. Please specify other indication for treatment.

Finally, for query texts popping up during CRF data recording, it could be helpful to put location information in it. Like: Page 12: Please verify start date. (Ensure that start date is after or at start date on page 11.)

Good luck finding your way to structure query texts…


This article is written by Maritza Witteveen of ProCDM. For clinical data management. You can subscribe to her blog posts at www.procdm.nl.”

Comments? Join us at {EDC Developer}

Anayansi Gamboa, MPM, an EDC Developer Consultant and clinical programmer for the Pharmaceutical and Biotech industry with more than 13 years of experience.

Available for short-term contracts or ad-hoc requests. See my specialties section (Oracle, SQL Server, EDC Inform, EDC Rave, OpenClinica, SAS and other CDM tools)

As the 3 C’s of life states: Choices, Chances and Changes- you must make a choice to take a chance or your life will never change. I continually seek to implement means of improving processes to reduce cycle time and decrease work effort.

Subscribe to my blog’s RSS feed and email newsletter to get immediate updates on latest news, articles, and tips. I am available on LinkedIn. Connect with me there for technical discussions.

Fair Use Notice: This article/video contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law. If you wish to use this copyrighted material for purposes that go beyond fair use, you must obtain permission from the copyright owner. Fair Use notwithstanding we will immediately comply with any copyright owner who wants their material removed or modified, wants us to link to their website or wants us to add their photo.

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary. If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

Disclaimer:De inhoud van deze columns weerspiegelen niet per definitie de mening van {EDC Developer}.