Tips for Writing Effective Edit Checks in eCRFs

Shannon Roznoski
Director, Product Management, Forte
February 10th, 2015

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. 

Forte EDC Product Overview

Compliance doesn't have to be complicated

Download the overview
Data Management EDC


11 thoughts on “Tips for Writing Effective Edit Checks in eCRFs

  1. We are moving more and more to risk-based monitoring and this requires us to be able to close queries in-house and decrease the amount of site visits. This requires us to write the query in a way that we can close it without re-visiting the source.

    An example of this would be: “Per the ER source dated 11JAN2015, the subject weight is documented as 140lbs, however the data entered is 160lbs. Please review the source and confirm the subject’s weight and update as necessary.”

    From what I have read, this would be inappropriate, however without adding the information as to what the monitor noted in the source during the visit, the monitor would not be able to close this query out without going back to the site.
    Obviously, if the site disagrees with the monitor after looking at the source (the 6 looks like a 4 but really is a 6), then the monitor would not be able to close this query without going to the site to re-confirm the source.

    If you have any suggestions as to better do this, please let me know. Hopeful that someone is still available for this string, even though it is over a year old. Thank you.

  2. Thank you for your comment.

    In terms of the specific question related to query text, I don’t think the sample text provided is inappropriate because you are not leading the site to a specific answer. You are simply stating the values as observed in the source versus the EDC system. Whether you need to re-review the source document to close the query would be up to the data monitoring policies of your company.

    I would propose though, that if your organization is moving towards more Risk Based Monitoring (RBM), you may want to consider a more dramatic change to your data review processes in order to fully reap the benefits of this approach. One of the big changes in RBM over previous monitoring and review strategies is to reduce source document verification in favor of other monitoring activities. These activities may include reviewing data in aggregate to identify outliers and looking at quality indicators between sites and subjects to identify risk areas for further investigation. SDV may still be a part of this monitoring strategy but may be limited to a much smaller percentage of a few critical data points. This enables monitors to focus other activities such as process audits, site training and other key topics when they do visit the sites.

    Here is a link to the abstract of an article that talks about the percentage of errors detected by SDV and provides a strong argument for reducing SDV in support of other monitoring activities.

    1. I appreciate your response and it helps me but I have had colleagues tell me that when I write queries in the manner mentioned that I am in fact leading. I agree with your response that it is not leading. Could you provide more rationale for why it is not leading?

      1. I’m sorry, but I don’t have much to add. Edit check language is up to interpretation and is both an art and a science. I happen to agree with your interpretation but others may find the second sentence of your example to be too instructive and, thus, leading. Another way you could word a similar check is below.

        Per the ER source dated 11JAN2015, the subject weight is documented as 140lbs, however the data entered is 160lbs. Please confirm the subject weight.

        I hope this helps.

  3. Is DVS and Edit check specification is same. What is edit check .what is logic .

  4. Hi, what will be the effect of DSUR and PSUR on edit checks development, if any safety and efficacy or any new information evolved. kindly explain

    1. If a Development Safety Update Report (DSUR) or Periodic Safety Update Report (PSUR) provides new safety and efficacy information that would result in the team wanting to monitor or track additional information for certain adverse events or conditions, it could result in changes to the forms or edit checks. This would need to be evaluated on a case by case basis per protocol.

Comments are closed.