Data integrity and ALCOA+: a practical shop-floor guide

Data integrity is the assurance that information remains complete, consistent, accurate and trustworthy throughout its lifecycle. On the shop floor, it is built—or weakened—one entry, calculation, result, correction and review at a time.

ALCOA+ is useful only when translated into behaviour and system design. A perfectly written policy cannot compensate for shared passwords, unofficial worksheets, inaccessible instruments, retrospective entries or reviewers who check signatures but not the underlying evidence.

ALCOA+ translated into daily work

Think in terms of the complete data lifecycle

1. Define which data and metadata are GMP-relevant.
2. Design a reliable method of capture at the point of activity.
3. Process and calculate through controlled methods.
4. Review the record and the underlying data at a depth proportionate to risk.
5. Report and use results without selective exclusion.
6. Retain records in a protected, retrievable form.
7. Destroy them only through an authorised process after the retention period.

Controls should cover paper, hybrid and electronic processes. Risk often concentrates at interfaces: manual transcription from an instrument, temporary worksheets, exports to spreadsheets, scanning, system migration and transfer between departments.

Manufacturing examples

Example 1: a late batch-record entry

An operator performs an in-process check but is called to an alarm before recording it. Thirty minutes later, the operator enters the result without explanation and uses the earlier time.

Integrity problem: the record falsely appears contemporaneous. Appropriate response: enter the actual recording time, identify the activity time where supported, explain the late entry according to procedure and allow Quality to assess impact. Never backdate.

Example 2: an incorrect equipment-log entry

A cleaning date is entered incorrectly. The original remains readable, a single line is drawn through it, the correct entry is added, and the correction is signed and dated with a reason where required. Correction fluid, overwriting or destroying the page would break traceability.

Example 3: unofficial yield calculations

A supervisor calculates yield on a personal spreadsheet because it is faster than the approved form. Even if the number is correct, the uncontrolled formula, missing version history and unretained intermediate data make the process unreliable. The solution is a validated or appropriately controlled calculation tool—not asking people to be more careful.

Example 4: shared machine credentials

A packaging line uses one generic operator account. Actions cannot be attributed and supervisors cannot distinguish an authorised adjustment from an error. Individual accounts, appropriate roles, session controls and periodic access review are system controls; signing a paper log after the event does not repair weak attribution.

Laboratory examples

Example 5: repeated injections

An analyst repeats a standard preparation until system suitability passes and reports only the successful sequence. The complete record must include the original sequence, failed or aborted runs, audit trail, reason for repetition and authorised scientific assessment. “Test into compliance” is not made acceptable by hiding attempts.

Example 6: manual integration

Manual integration may be scientifically justified, but it needs predefined governance: authorised roles, retained original and reintegrated data, visible audit-trail history, documented rationale and meaningful second-person review. A cleaner-looking chromatogram is not a scientific justification.

Example 7: sample weights on scrap paper

Weights first written on an uncontrolled sheet and later transcribed create an ungoverned original record. Provide a controlled worksheet at the balance, direct electronic capture or another approved contemporaneous method that retains the first capture.

Example 8: excluded atypical result

A result is excluded as a “laboratory error” without demonstrable evidence. Data integrity requires retaining the result and following the approved investigation process. An assignable cause must be supported, not inferred because a retest passed.

What a meaningful data review checks

• Expected records exist and their chronology is credible.
• Calculations, transcriptions and units are correct.
• Corrections and changes are traceable and justified.
• Electronic metadata and audit trails are reviewed where risk requires it.
• Aborted, deleted, invalidated and repeated activities are explained.
• Access rights and electronic signatures match assigned responsibilities.
• Results have not been selectively reported.
• Source data can reconstruct the decision and the work performed.

Culture, workload and system design

Data-integrity failures are not always deliberate falsification. Poorly located terminals, unrealistic workloads, confusing forms, weak access design, fear of reporting mistakes and performance targets that reward only passing results can predictably create unreliable records.

Management should protect open reporting, investigate system causes, provide sufficient time and resources, and distinguish an honest error from intentional misrepresentation. Accountability remains necessary, but a blame-only response drives problems underground.

When a potential integrity issue is found

1. Protect the data and prevent further alteration or loss.
2. Notify the authorised supervisor and Quality function promptly.
3. Preserve accounts, audit trails, paper records, backups and relevant equipment state.
4. Define the event without prematurely labelling intent.
5. Assess product, patient, validation, regulatory and reporting impact.
6. Determine scope across users, systems, products, methods and time periods.
7. Investigate direct, contributing and organisational causes.
8. Correct the immediate issue and implement sustainable CAPA.
9. Verify effectiveness using predefined evidence.

For investigation structure, use the deviation-investigation guide; for sustained verification, use the CAPA effectiveness guide.

Common mistakes

• Treating ALCOA+ as a training acronym rather than a control framework
• Assuming printed output is always the complete original record
• Allowing shared accounts or administrator access without justification
• Reviewing audit trails as a checkbox without defining risky events
• Permitting unofficial notebooks, worksheets or calculation files
• Discarding failed, aborted or inconvenient data
• Backdating or reconstructing entries without transparent explanation
• Buying software while leaving the underlying workflow uncontrolled
• Limiting scope to one person when the system enabled the behaviour

Educational notice: This article provides general education. Follow your approved procedures and applicable regulatory requirements.