Correction harder than entry

When corrections are harder to request or complete than initial entries, users may delay reporting uncertainty. Review the correction route as well as the approval requirements.

Users should be able to initiate a correction. Who may edit, approve or reverse it depends on the record’s type, state and applicable controls. Preserve the original information and the reason for the change.

• Slow or unclear correction requests can discourage timely recording; supervisor approval may still be required.
• Entries are delayed until someone is sure.
• Corrections pile up as small adjustments at period end.
• For electronic records subject to 21 CFR Part 11 in closed systems, 21 CFR 11.10(e) requires that record changes shall not obscure previously recorded information.
• Blaming operators for data quality is a common response that leaves the cause in place.

• Corrections requested by message or email
• Entries delayed until someone is sure
• Many small adjustments at period end
• Users ask colleagues to check before they record anything

Records locked to protect them. Locking a record after entry looks like control. It moves corrections into messages and tickets, outside the audit trail.

Correction treated as an administrator’s task. Correction screens are built for the vendor’s team or an administrator and never designed for the person who made the entry.

• Skipped entries. Uncertain transactions go unrecorded.
• Late data. Entries wait until someone is sure, so the system lags behind the floor.
• Period-end noise. Many small adjustments at period end hide the reasons for each difference.
• Corrections outside the record. Fixes requested by message leave no trace of who asked or why.

Where it shows up

• Scan-first input with manual fallback
• Traceability design
• Quality management systems (QMS)
• How should audit trails and activity history work?
• How do interface problems cause bad production data?

Sources: eCFR, 21 CFR 11.10