Tag Archives: manual queries

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.

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

Data Management: Queries in Clinical Trials

When an item or variable has an error or a query raised against it, it is said to have a “discrepancy” or “query”.

All EDC systems have a discrepancy management tool or also refer to “edit check” or “validation check” that is programmed using any known programming language (i.e. PL/SQL, C# sharp, SQL, Python, etc).

So what is a ‘query’? A query is an error generated when a validation check detects a problem with the data. Validation checks are run automatically whenever a page is saved “submitted” and can identify problems with a single variable, between two or more variables on the same eCRF page, or between variables on different pages. A variable can have multiple validation checks associated with it.

Errors can be resolved in several ways:

  • by correcting the error – entering a new value for example or when the datapoint is updated
  • by marking the variable as correct – some EDC systems required additional response or you can raise a further query if you are not satisfied with the response

Dealing with queries
Queries can be issued and/or answered by a number of people involved in the trial. Some of the common setups are: CDM, CRA or monitors, Site or coordinators.

Types of Queries

  • Auto-Queries or Systems checks
  • Manual Queries
  • Coding Queries
  • SDV related Queries generated during a Monitor visit
  • External Queries – for external loaded data in SAS format

EDC Systems and Discrepancy Output Examples

InForm

Note: All queries are associated to a single data item relevant to that query.

RAVE

Note: Users are only able to see / perform an action on a query based on their
role and the permissions via Core Config.

Timaeus

Note: Queries are highlighted by a red outline and a Warning icon.

OpenClinica

Note: Extensive interfaces for data query.

Query Metrics – It is important to measure the performance of your clinical trials.
Metrics are the same for all clinical studies but not all EDC systems are the same. Standardized metrics encourage performance improvement, effectiveness, and efficiency. Some common metrics are:

  • Outstanding Query
  • Query Answer Time
  • Average Time to Query Resolution
  • Number of closed discrepancies on all ongoing studies

Data management’s experience with data queries in clinical trials

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

Trademarks: InForm is a trademark or registered trademark of Oracle Corporation. Rave is a trademark or registered trademark of Medidata. Timaeus is a trademark or registered trademark of Cmed Clinical Research.


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.