thebench.bio #1 Ecosystem for the Bio-Tech Industry
All Clinical Data Management questions

Question 11 of 20 Intermediate Troubleshooting

A database edit check creates hundreds of false queries. How would you diagnose the rule?

Short answer

Pause or suppress the check through change control, then compare the specification, the programmed logic and the data that fired it. Most false positives come from a wrong unit, a missing condition, a wrong visit or a range that ignores real clinical variation. Fix, retest in a test environment and close the false queries with a documented reason.

Why

False queries waste site time and teach sites to answer queries without reading them, which is when real errors slip through. EMA's computerised systems guideline says edit checks should be validated, implementation should be controlled and documented, and pausing a check should be documented and justified. So the fix follows change control even when it is urgent.

Start with a sample of fired queries and look for a pattern. If all come from one country, a unit difference is likely, such as glucose in millimoles per liter checked against a range in milligrams per deciliter. If they fire on every scheduled visit, a condition may be missing, such as checking a field the protocol only requires at baseline.

If they fire on derived values, the derivation may run before all inputs are entered. Then compare the specification wording with the code, since the error can sit in either. After correcting, test with positive and negative cases, including the records that fired.

Close the false queries in bulk with a clear reason, and tell sites what happened.

How to work it through

  1. Stop the check from firing new queries through documented change control.
  2. Pull a sample of the false queries and look for a common factor such as site, visit, unit or form version.
  3. Compare the specification with the programmed logic line by line.
  4. Write test cases that should and should not fire, including the real records involved.
  5. Deploy the corrected check after testing in a non-production environment.
  6. Close the false queries with a reason and tell sites what changed.

An example

A check flags hemoglobin outside 12 to 18 and fires 640 queries in a week. A sample shows 92 percent come from sites in two countries. Those labs report hemoglobin in millimoles per liter, where normal is about 7.5 to 11, so every value looks low.

The specification assumed grams per deciliter but did not require a unit field. The fix adds the unit to the check and converts millimoles per liter to grams per deciliter by multiplying by 1.611 before comparing. Testing on 50 records shows no false firing, and 588 queries are closed with the reason 'unit not considered'.

Where the answer stops holding

Some checks fire often because the data really are bad, so a high query rate is not proof of a bad rule. Widening a range to stop queries can hide true outliers. Changes after data are entered may need a decision on whether to re-run the check on historical records.

A strong answer covers

  • Change control even for urgent fixes
  • Look for a pattern across site, visit, unit or form version
  • Compare specification with code
  • Positive and negative test cases
  • Close false queries with a reason and inform sites

Common mistakes

  • Deleting the check rather than fixing it.
  • Editing the check directly in production without testing.
  • Asking sites to answer every false query individually.