Edit checks are a great mechanism to help improve data quality within an electronic data capture (EDC) system. There are many benefits to creating them in electronic case report forms (eCRFs) such as real-time feedback for site staff as they enter data, early resolution of data discrepancies, and automated review, allowing monitors and data managers to focus on more complex review tasks. Since programming edit checks takes time and resources, it’s important to ensure that the effort invested maximizes the benefit and reusability of each edit check. Here are a few tips that can come in handy when writing edit checks in eCRFs.
Determine which edit checks are essential to program
It is easy to think of a nearly unending list of potential edit checks, but many of them are extremely unlikely and all will require development and testing. Most scenarios will use standard or protocol-specific edit checks.
Standard edit checks
If you’re able to program 10 standard checks into a form template, test the form and then reuse the form on most protocols, you are getting a lot for your initial investment of time and testing. Consider defining a standard library of form templates and edit checks that address common data entry errors via standard checks, and can be applied to most studies.
Try to minimize protocol-specific edit checks and use standard form templates with standard edit checks when possible. Checks to ensure that stop dates are after start dates and other logic checks are generally applicable to all studies and can be included in your standard form templates.
For critical data, such as dosing and adverse events, you may want more extensive checks to cover scenarios that occur less frequently.
Protocol-specific edit checks
There will be instances when it makes sense to add protocol-specific checks, particularly for critical data points and unique protocol procedures. Protocol eligibility criteria, such as age, vary from protocol to protocol and may need to be created as protocol-specific checks. Additionally, assessments for primary endpoint analysis are critical to the success of the protocol, vary from protocol to protocol, and benefit from additional checks to ensure the highest level of quality.
Also consider the type of study when determining the extent of programmed protocol-specific checks. For example, in a small Phase I study with 24 subjects, it may be more efficient to manually review the data for a few complicated scenarios than it would be to configure and test programmed edit checks. In a larger late phase study, the initial effort of programming and testing may be worth the benefit over the long run.
Build custom forms, set up edit checks, use forms across multiple protocols and more. Learn more about Forte EDC.
Elements of an edit check
Once you determine the checks to program, ensure that each check fires only when needed and provides a clear message to the site.
Write simple checks
Make the logic as clear and simple as possible. It is easier to test two or three simple checks than one extremely convoluted check with several IF statements or a lot of nested logic.
Write clear edit check messages
Since the site staff does not see the logic used to generate the check, they must be able to understand the issue from the edit check message alone. When writing edit check or query messages consider providing clear answers to the following:
- What – Clearly define which fields are at issue.
- Why – Explain why there is a potential data error.
- Next Steps – Prompt the user for action, without leading the site to a specific outcome.
Using the criteria above, here’s an example of an edit check message that demonstrates clarity for site staff:
Adverse Event #2 Start Date is after Study Completion Date. Per protocol, adverse events are to be collected from Informed Consent to Study Completion. Please confirm Adverse Event and Study Completion dates.
The example above answers the questions of:
- What – Adverse Event #2 Start Date is after Study Completion Date.
- Why – Per protocol, adverse events are to be collected from Informed Consent to Study Complete.
- Next Steps – Confirm Adverse Event and Study Completion dates.
Common pitfalls to avoid
While there are many approaches for what you can do when writing edit checks, keep in mind there are a few things not to do.
Do not lead the site
Queries should be written in an unbiased way that doesn’t lead the site to a specific answer. Write queries that indicate the error, why it is an error, and lets the site determine the appropriate action.
Do not set narrow ranges
Ranges programmed into edit checks should reflect a wide range of possible values rather than a narrow range of normal or expected values. Generally, the purpose of range checks is to ensure that data entry mistakes are corrected. If the ranges are set too narrow, the team will end up answering, reviewing and closing a large number of queries for valid, but out of range results. This takes time for the site and CRA or DM staff and can be extremely frustrating for the team.
Without effective edit checks, there is a risk of increased effort for the entire team and risk of decreased clinical data quality. Consider these tips as a starting point to yield the best return from your time and improve the quality of your clinical data.
Editor’s Note: This blog post was originally published on March 13, 2014.
Need an easy-to-use EDC system?
Forte EDC allows users to build custom forms, set up edit checks and use forms across multiple protocols to decrease duplicate data entry and error.