Data Integrity

Data integrity is the degree to which data remain complete, consistent, accurate, trustworthy and reliable throughout their lifecycle. This follows the definition in PIC/S PI 041-1, glossary entry Data Integrity.

In manufacturing and laboratory practice, GMP data integrity, GxP data integrity and DI refer to this concern in regulated work. The evidence may include paper worksheets, instrument files, electronic batch records and hybrid arrangements connecting paper with electronic data. Integrity is not simply database maintenance or protection against corrupted files.

The object of review is the evidence supporting a decision: observations, relevant context, processing history and retained records. A result within specification does not, by itself, establish that the evidence is complete. For example, a passing laboratory report may not reveal an omitted measurement or a processing change that affected interpretation. The distinction between dynamic and static records helps explain why a readable report may not preserve everything needed for review.

The practical question is whether a reviewer can reconstruct the activity and understand how the reported result was reached. Follow the record across the people, instruments and systems involved rather than stopping at the application that displays the final result.

Use these overlapping working distinctions to match a problem with the right control and the right review question.

For example, a restricted folder may contain only selected test results. Access protection alone cannot establish that all observations were captured. Use data integrity by design to build capture and review controls into the workflow.

Map controls to the product, activity, jurisdiction and records they cover. Keep four categories separate when documenting the basis for a control:

Binding examples: availability and retention

For records required under Part 211, 21 CFR 211.180(c) requires records or copies to be readily available for authorised inspection during retention at the establishment where the recorded activities occurred. It also accepts records immediately retrieved from another location by computer or other electronic means.

Test off-site retrieval, not just backup existence. Use the 21 CFR 211 overview to organise applicability and the Part 11 scope discussion for electronic-record questions. For GxP cloud storage, exercise the permissions, staff access and supplier dependencies needed to retrieve the selected record.

For production, control or distribution records required by Part 211 and specifically associated with a drug-product batch, 21 CFR 211.180(a) sets a minimum retention period of one year after batch expiration. The same paragraph specifies three years after distribution for certain OTC drug products without expiration dating because they meet the exemption criteria in § 211.137.

A retention register should identify the trigger and its source, not just a duration. “Keep for one year” does not identify when the clock starts. Give shared records a rule covering linked batches, and address continued access in system decommissioning planning.

Guidance example: technical restrictions

FDA’s guidance-status explanation says its guidance generally does not establish legally enforceable responsibilities. Recommendations remain distinct from the statutory or regulatory requirements they cite. In Question 4, FDA recommends technical restrictions on altering specifications, process parameters, data, or manufacturing or testing methods where possible. To evaluate implementation, compare permitted edits by role with observed system behaviour.

Complete the jurisdiction check

For EU medicinal products, check the applicable legal framework and the status of Annex 11 and Chapter 4 separately. For supplements, food, devices and chemicals, build a sector-specific map rather than transplanting pharmaceutical requirements.

Record the governing version, scope rationale, exact provision, control owner and verification evidence. A retrieval date alone does not establish which version governs the activity.

PIC/S guidance in PI 041-1 section 5.2.3 recommends lifecycle controls proportionate to quality risk management. Adapt the following allocation of responsibilities to the site's activities and authority structure:

• Process owners define what records mean, their intended use and the evidence needed to interpret them.
• Laboratory and manufacturing personnel capture observations and report omissions, mistakes and unexpected results.
• Quality reviewers assess evidence and resolve or escalate discrepancies; assign responsibility for the audit trail review workflow.
• System owners coordinate intended use, configuration decisions and controlled changes.
• IT administrators operate storage, access administration and recovery arrangements. Operating the platform does not confer ownership of the scientific or manufacturing meaning of its records.

Assign a senior manager to oversee these arrangements. Name escalation contacts and deputies, set triggers for quality escalation, and allocate sufficient review time. Managers should support investigations into errors and undesirable results without pressuring staff to obtain acceptable results. Where one person holds several roles, document how their work is reviewed and unresolved conflicts are escalated.

For outsourced evidence, PIC/S PI 041-1 section 10.3.1 recommends regular risk reviews of supply chains and outsourced activities. Apply this guidance in external laboratory oversight and CMO/CDMO management by asking: Which source data are available? Can site reviewers access them? How are records transferred and receipt confirmed? Who investigates discrepancies, supplies missing evidence and authorises closure? Record the answers in operating agreements, with named contacts on both sides. Outsourcing an analysis should not leave responsibility for interpreting or challenging its evidence undefined.

The PIC/S PI 041-1 glossary (section 13) describes the data lifecycle, including raw data, from initial generation and recording through processing, use, retention, archive/retrieval and destruction. Processing includes transformation or migration. The workflow below is an illustrative site practice, not a regulatory sequence.

At each handoff, identify the input record, receiving role and evidence of completion. Processing completion is not review approval; a review signature does not demonstrate that the retained record can still be retrieved.

Plan recovery alongside retention. MHRA guidance section 6.17.2 recommends validating and periodically testing backup and recovery processes.

Illustrative evidence-handling workflow

1. Prepare: identify the activity, applicable method and recording route before work starts. Confirm that the operator has the correct instructions.
2. Capture: record source observations during the activity using contemporaneous recording. Hand over the observations, not just a selected summary.
3. Process: link source observations to derived results, calculation settings and any reprocessing. Retain enough processing history for the reviewer to reconstruct how the reported result was obtained.
4. Review: compare the evidence with the intended activity and document unresolved exceptions. Route results outside specifications through out-of-specification handling; separately escalate other data concerns.
5. Decide: an authorised person records the assessment and disposition, including the effect of exceptions. Workflow completion does not itself authorise quality release.
6. Retain and retrieve: preserve data with the metadata needed to reconstruct the activity. Check usable retrieval after migration, restoration or archival access.
7. Dispose: check record-specific retention obligations and outstanding holds before authorised destruction; record its scope, approval and completion.

A measured value of 98.4 is not self-explanatory. Assume an assay result of 98.4% of label claim: units and reporting basis establish the scale; sample and batch identity establish what was tested; instrument and method version establish how; operator identity establishes who; recording time establishes when the result entered the record. These links provide production context, not merely labels.

Distinguish measurement time, entry time and transfer-receipt time; preserve each timestamp’s meaning and time zone. Clock drift monitoring helps investigate apparent sequencing differences, but does not by itself establish the true order of events.

MHRA guidance in section 6.13 describes audit trails as metadata associated with record creation, modification or deletion. PIC/S PI 041-1, page 49 recommends evidence that reporting summaries have been verified against raw data.

Illustrative five-entity evidence model

Here, record_id links an observation to changes, transfer receipts and decisions; method_version_id identifies the method used. observation_version links a decision to the specific state reviewed, so a later correction does not silently change what that decision covered. Retain the referenced versions.

Transfer receipts belong to this model because each one points back to a source_event_id; how expected events, delivery attempts and postings are reconciled is covered under integrations below. Keep the observation and subsequent human interpretation distinct so reviewers can reconstruct the evidence considered.

Applying the evidence-completeness distinction above, these hypothetical cases test whether reviewers can reconstruct events. They illustrate review practice, not product release criteria.

1. Selective laboratory reporting

• Assumptions: The approved reporting plan specifies the arithmetic mean of three valid, equally weighted assay replicates: 98.0%, 100.0% and 102.0% of nominal label claim.
• Apparent result: Reporting only 100.0% and 102.0% gives (100.0 + 102.0) ÷ 2 = 101.0%. The complete mean is (98.0 + 100.0 + 102.0) ÷ 3 = 100.0%. The omission shifts the reported mean upward by 1.0 percentage point.
• Failure and review: Reconcile all three source results, investigate the omission, and retain the original report with a traceable correction. The example assumes all three replicates are valid; it does not justify averaging invalid results.

MHRA’s guidance, §6.10 recommends excluding data only where valid scientific justification demonstrates that they are not representative of the quantity measured, sampled or acquired. It also recommends documenting the justification for review and retaining excluded data with the original dataset.

Closure evidence should identify which report used 101.0%, who received it, and how the corrected 100.0% result was communicated. Check whether the selected mean also fed another calculation or batch decision; correcting one display may leave that use unchanged. Record the affected records and reviewer decision. Handle any separate specification failure through out-of-specification handling rather than changing the assumed reporting plan.

2. Duplicate transfer after a retry

• Assumptions: One dispensing event measures 12.500 kg and is transmitted as 12,500 g. A retry produces two received messages with the same source event identifier.
• Apparent result: Adding both receipts gives 12,500 g + 12,500 g = 25,000 g = 25.000 kg. The physical quantity remains 12.500 kg.
• Failure and review: Reconcile both receipts to the source event, verify the unit conversion and preserve retry evidence, applying the event-identity control described under integrations so material consumption posting and in-process reconciliation include the event once.

For automated capture, PIC/S §9.7 guidance recommends validated checks for completeness of acquired data and associated metadata. Apply that recommendation to three challenge cases:

These are site-defined tests for the posting interface, not assumptions that message identifiers are globally unique. Include the originating system in the identity rule when separate systems can reuse identifiers.

3. Later transcription of a timely source record

• Assumptions: An instrument log captures an observation at 10:05 despite a printer interruption. A person transcribes it into a secondary record at 10:17 on the same date, using synchronized clocks in the same time zone.
• Apparent result: Transcription occurs 12 minutes after source capture. That delay alone does not make the original recording noncontemporaneous.
• Failure and review: The secondary record mislabels 10:05 as its entry time. Link the original log, preserve the 10:05 event time and actual 10:17 entry time, and document the interruption, entrant and review decision. Distinguish source capture from transcription when assessing contemporaneous recording.

The same PIC/S guidance recommends recording the entrant and entry time, and verifying manual critical-data entries by a second operator or validated computerised means.

For this case, a second-person check should compare the transcribed value, units and sample identity against the 10:05 log, not merely confirm that fields are populated. If clock accuracy is unverified, describe the 12 minutes as an indicated difference pending clock-drift assessment rather than a confirmed elapsed interval.

Treat an interface as four stages: source generation creates the observation; transport carries it; destination acceptance confirms receiving checks passed; business posting applies it to an operational record. These are recommended engineering and quality controls, not standalone legal requirements.

Preserve source and event identities, units, timestamps, mapping version and acknowledgement status where relevant. A linked process event log should distinguish delivery attempts, accepted events and completed postings.

Reconcile each unique expected event to its current accepted, rejected or unresolved status; check posting separately. Preserve attempt history when an event's status changes. Expose rejected rows within partial imports rather than marking the whole file successful. Investigate delayed acknowledgements before retrying; define handling for out-of-order arrivals; retain original values alongside unit conversions and their rules.

Use idempotent posting: receiving the same identified event again should not create another material consumption posting for one withdrawal. This controls duplicate recording, not repeated physical withdrawal. Test duplicate delivery and retries, including loss of an acknowledgement after posting.

Recover with a defined evidence boundary

Contain the affected interface or activity, preserve available source evidence, identify the uncertain time window, reconcile affected records, document corrections or reprocessing, and obtain designated human review.

For temporary paper capture, migrations and service restoration, specify which records are authoritative before, during and after the interruption or transition. Retain links between temporary records and subsequent entries so reviewers can trace reprocessing without counting it as new activity.

Before routine use resumes, test for omissions, duplicates, changed values and unresolved postings, and document the disposition of discrepancies. Successful transport, printing or backup restoration alone does not demonstrate integrity.

Use these diagnostics to connect observable warnings with a suggested control owner and evidence to inspect. A configured control or clean sample does not prove absence of a problem.

An editable formula is a vulnerability; a verified unauthorised formula change is an incident. Neither alone establishes intentional falsification. Preserve relevant files, metadata, logs and settings before remediation alters them. Determine affected records, batches and time periods, then assess product impact and cause. Document uncertainty and the basis for conclusions. Use a CAPA effectiveness check to test whether corrective controls work.

MHRA GXP Data Integrity Guidance section 3.5 says routine data checking need not be forensic. It also recommends appropriate system controls and periodic audits capable of detecting opportunities for data integrity failures.

Use a test environment to correct an entry, interrupt a transfer, resend the same message and record a later reviewer decision. Judge the resulting evidence, not a feature checklist.

• Reconstruct the transaction. Which instruction version applied? Who entered and changed the record? Are the original value, correction and supporting metadata available? Can the reviewer locate unresolved exceptions?
• Test transfer handling. Does resending create a duplicate result? Can the reviewer reconcile the source and destination and identify missing, rejected or incomplete transfers?
• Test continuity. Request a readable evidence package and demonstrate historical-data access after export, an upgrade and recovery. Ask what remains accessible after contract termination, including any review functions lost in a static export.
• Separate responsibilities. Identify which controls depend on application behaviour, customer configuration, infrastructure or procedures. For cloud services, name who provides recovery evidence and who verifies usability.
• Expose limitations. Demonstrate privileged-access capabilities; list unsupported formats and integration assumptions. Record untested scenarios, manufacturer responsibilities and an owner for each follow-up.

Use the findings in computerised system validation and commissioning and decommissioning planning. MHRA guidance in section 4.5 explains that automation or a validated system may lower, but not eliminate, data integrity risk.

Use this site-tailored practice checklist to test whether controls work, not merely whether procedures exist. Set risk-based acceptance criteria and retain evidence for each conclusion.

• Inventory: reconcile listed processes and records against a walkthrough of manufacturing, laboratories, paper records and external services; resolve omissions.
• Ownership: confirm named owners for processes, systems, review handoffs and supplier interfaces, including escalation cover.
• Record boundaries: check an approved record map against a completed record, including source observations, metadata, audit trails, attachments and retained outputs.
• Traceability: reconstruct a selected reported result from source data, including transformations and excluded data; document reconciliation.
• Permissions: test permitted and prohibited actions with representative accounts; retain results and resolve discrepancies.
• Exception exercises: test interruption, retry and correction scenarios in a controlled environment without altering live GMP records; reconcile missing or duplicate records.
• Retrieval: retrieve a complete, readable historical record with its context; document missing dependencies and their resolution.
• Reviewer competence: use seeded discrepancies in training records to test recognition, investigation and escalation, rather than relying on attendance.
• Corrective actions: assign owners and due dates, verify implementation, then document a CAPA effectiveness check against defined criteria before closure.

PIC/S PI 041-1 section 5.6.1 recommends periodically assessing data integrity control effectiveness through self-inspection or other periodic review processes. Treat this as guidance, not a statutory review interval; document the site's review timing and rationale.