Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics -> Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Work Instruction Plug-and-play starting point Cell & Gene Therapy

Work Instruction: Manual Data Transfer Verification for Unintegrated GxP Systems

A plug-and-play, task-level work instruction for moving data by manual export between two GxP systems that lack a validated electronic interface: field boundary definition, value-for-value or checksum verification, format-lock checks, and source retention, with per-step acceptance and a filled specimen.

Document type: Work Instruction

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use work instruction for the moment a value or a file has to move from one GxP system to another with no validated electronic interface between them, an instrument exporting a CSV into a spreadsheet, a spreadsheet result keyed into a LIMS, a closed platform’s data file copied into a document management system. This kind of manual bridge shows up constantly in cell and gene therapy operations because the system estate is large and integration is often incomplete, and every bridge is a point where a value can be transcribed wrong, truncated, or silently altered. It is task level: the specific checks a person performs, not the policy behind them. Replace every <<FILL: ...>> placeholder, set your document numbers, and route it through document control. A filled specimen follows. Verify each cited regulation against the current source. This is general guidance to adapt, not legal or regulatory advice.

Document control header

FieldEntry
Document titleManual Data Transfer Verification for Unintegrated GxP Systems
Document number<<FILL: WI-ID, e.g. WI-QA-057>>
Version<<FILL: version>>
Effective date<<FILL>>
Parent SOP<<FILL: SOP-ID, e.g. data governance / data integrity SOP>>
Owner<<FILL: role, e.g. Data Governance Lead>>
Applies to<<FILL: named system pairs in scope, e.g. flow cytometer to LIMS>>

Purpose and scope

This work instruction defines the step-by-step check a person performs whenever data moves between two GxP systems by a manual route, an export and re-import, a copy-paste, a keyed transcription, rather than through a validated electronic interface. It applies to any such bridge feeding a result used for disposition, comparability, or a regulatory submission. It does not replace the qualification of a validated electronic interface where one exists; see the Form: Interface Data Mapping Verification and Reconciliation Record for that case. It also does not replace the review defined in Work Instruction: Vector Copy Number, Potency, and Replication Competent Virus Assay Data Review, which references this instruction for its own transfer step rather than repeating it.

1. Before the transfer

StepActionPer-step acceptance
1.1Identify the authoritative source record and confirm it is the original dynamic record, not already a derived copySource system and file/record identified and documented
1.2Define the exact field boundary, which fields move, in which order, and what the destination field is for eachField-by-field map recorded (see section 4)
1.3Confirm the destination is understood to hold a true copy, not a replacement; the source stays authoritative and retainedDocumented in the transfer record
1.4Confirm units, decimal places, rounding rule, and date/time format for each field before export, not afterFormat expectations recorded per field

2. Performing the transfer

StepActionPer-step acceptance
2.1Export or record the values using the defined method (file export, controlled copy, or keyed entry with a second person present for keyed entry)Method used matches the approved method for this system pair
2.2Capture who performed the transfer, from what source (file name, version, run ID), the exact timestamp, and the destination locationComplete and contemporaneous, entered on the transfer record
2.3Where a file transfer, generate and record a checksum or hash of the source file at exportChecksum recorded, or documented reason none is available

3. Verifying the transfer

StepActionPer-step acceptance
3.1A second person (not the person who performed the transfer) compares every moved value against the source, value for value, or reconciles the checksum for a file transfer100% of defined fields checked; no field skipped as “obviously fine”
3.2Confirm no value was reformatted in a way that changed its meaning, a dropped trailing digit, a rounded value, a date field silently switched from day-month-year to month-day-yearFormat integrity confirmed per field against section 1.4 expectations
3.3Confirm row count, record count, or file count matches between source and destination, with any intentional exclusion documentedCounts reconcile, or the discrepancy is explained and approved
3.4Where any discrepancy is found, stop, do not use the destination data, and route to section 5No unresolved discrepancy in a transfer used for disposition
3.5Reviewer signs and dates the transfer record before the destination data is usedDocumented second-person verification, dated, before use

4. Field mapping table (attach one per system pair)

Source fieldSource formatDestination fieldDestination formatTransform applied (if any)
<<FILL>><<FILL>><<FILL>><<FILL>><<FILL: none, or state exactly>>

5. Handling a discrepancy

  1. Do not use the destination value. Do not correct it silently to match the source.
  2. Notify the system owner and Quality Assurance the same working day.
  3. Determine whether the discrepancy is a one-time transcription error or a systemic format problem (for example, a spreadsheet auto-formatting a date field on every use).
  4. Open a deviation per <<FILL: SOP-ID>> where the discrepancy could have affected a result already reported or released.
  5. For a systemic cause, correct the transfer method (lock the destination field format, change the export template) before the bridge is used again, and document the fix.

Records generated

FieldEntry
System pair<<FILL: source system>> to <<FILL: destination system>>
Source file / record reference<<FILL>>
Source checksum (if applicable)<<FILL>>
Transfer performed by (name, date, time)<<FILL>>
Fields transferred<<FILL: reference to field mapping table>>
Verification result<<FILL: pass / discrepancy>>
Verified by (name, date)<<FILL>>
Discrepancy / deviation reference (if any)<<FILL: number or N/A>>

References

21 CFR 211.68 (automatic, mechanical, and electronic equipment), 211.194 (laboratory records). 21 CFR Part 11 (electronic records; true copies). EU GMP Annex 11 (computerised systems), including the true copy concept. FDA guidance, Data Integrity and Compliance With Drug CGMP (2018). PIC/S PI 041, Good Practices for Data Management and Integrity.

Confirm each reference against the current source before issue.


Filled specimen

An illustrative transfer of a droplet digital PCR vector copy number result from the instrument’s export file into a LIMS worksheet ahead of the potency calculation. Values are examples.

FieldEntry
System pairddPCR instrument software to LIMS worksheet LOT-3391
Source file / record referenceLOT-3391-VCN-R1.qlp, run 2026-08-14 09:12, exported as CSV
Source checksumSHA-256 recorded in export log, matches on verification
Transfer performed byM. Okonkwo, 2026-08-14 09:40
Fields transferredWell ID, target copies/uL, reference copies/uL, ratio (per field map, 4 fields, 8 wells)
Verification resultDiscrepancy found: well 6 ratio showed 3 decimal places in source, 2 in LIMS (spreadsheet auto-rounded)
Verified byT. Reyes, 2026-08-14 10:05
Discrepancy / deviation referenceDEV-2026-0611; LIMS worksheet decimal format corrected to match source precision, re-verified, all 8 wells pass

In this example the second-person check caught a spreadsheet auto-rounding a value from three decimal places to two, a difference invisible to a casual glance but capable of shifting a ratio near a specification limit. The transfer was held, the format was fixed at the cause rather than the symptom, and the corrected transfer was re-verified before the potency calculation used it.

Common inspection findings this work instruction prevents

  • A CSV export that silently dropped precision, reformatted dates, or truncated rows, discovered only when a downstream result looks wrong.
  • No record of who performed a manual transfer, from what source, or when.
  • A “verification” that consisted of a glance rather than a value-for-value or checksum check.
  • The source file deleted or overwritten once the destination spreadsheet exists, leaving no way to reconstruct the transfer later.
  • A systemic formatting problem (an auto-rounding spreadsheet, a locale date-format mismatch) that recurs across many transfers because the one-time fix was never generalized.

How to adapt this work instruction

  1. Point the parent SOP reference to your actual data governance or data integrity procedure.
  2. Build one field mapping table (section 4) per system pair in your estate; keep it under document control and update it whenever the export format changes.
  3. Decide, per system pair, whether checksum verification is feasible (file transfers) or value-for-value comparison is the only option (keyed or summary transfers), and say so in the transfer record.
  4. Where a system pair transfers frequently, consider whether the manual bridge should instead be replaced with a validated electronic interface; use this work instruction’s discrepancy history as the justification.
  5. Confirm every regulation against the current published version before issue.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.