Dynamic vs Static Records in GMP Data Integrity

Dynamic vs Static Records describes the difference between records that support interaction with their content and fixed records that allow little or no such interaction. For practical data integrity assessment, the question is what a reviewer can inspect and reconstruct—not whether the record looks complete on screen or paper. A useful assessment starts with the activity being documented and the evidence needed to understand it.

This article follows a decision sequence: identify the source record, establish the review functions needed, assess the proposed copy against those needs, and plan retention. That sequence gives laboratory, production and quality teams a shared way to discuss record formats before choosing an export, printout or archive approach.

The discussion connects format choices with electronic records, but keeps the format assessment separate from the question of which rules apply. The sections below distinguish guidance definitions, jurisdiction-specific obligations and practical implementation, then apply the reasoning to laboratory and shop-floor records.

For UK medicines GMP, MHRA section 6.11.1 describes a static record format as fixed, allowing little or no interaction between the user and the record content. This guidance definition concerns how the content can be used, not simply whether its carrier is paper or electronic.

• Paper observation: a handwritten description of material appearance presents the recorded observation without analytical functions.
• Image-only scan: a scanned worksheet presents an image of the page, rather than the underlying measurements as processable data.
• Fixed electronic report: an exported results report presents selected outputs without necessarily retaining the source application's calculation or reprocessing functions.

In practical assessment, searching text, magnifying a plot or adding annotations does not necessarily recover the source system's analytical functions. A viewer may enlarge a plotted trace without enabling recalculation from its measurements. PDFs are not all technically identical: assess the particular file's content and capabilities rather than classifying it solely by its extension.

Format is also separate from authenticity and correctness. A static record can be authentic yet inaccurate; an interactive record can be well controlled or poorly controlled. Good documentation practices, including attributable recording, address reliability rather than format alone. Original-record status and copy acceptance are separate assessments, addressed in the dedicated section below.

For UK medicines GMP, MHRA section 6.11.1 describes dynamic records as allowing an interactive relationship. For US drug CGMP, FDA Question 10 identifies the FT-IR spectral file as dynamic and capable of reprocessing. These are guidance descriptions, not interchangeable labels for every electronic file.

In practice, useful interaction depends on the source data and the reader: a reviewer might explore a spectral region or examine source signals behind a processed result. Read-only access can preserve that exploration without granting permission to overwrite data. Controlled processing may be available through a separate authorised workflow; it is an example of interaction, not a universal capability of electronic records.

Raw data and dynamic data therefore answer different questions. For a practical data integrity assessment, identify what the reviewer can actually inspect or do with the retained record, rather than relying on its filename or electronic storage alone. The next section addresses when a printout or copy can represent the original.

The useful question is not whether a record is printed, but whether it preserves the evidence needed to understand and reconstruct the activity. Assessing original records and true copies is therefore a data integrity decision, not simply a choice of file format.

FDA's 2018 data integrity Q&A (US drug CGMP guidance) answers Question 10 in two parts. A paper printout or static record "may satisfy retention requirements if it is the original record or a true copy of the original record", as with pH meters and balances. But electronic records from certain laboratory instruments "are dynamic, and a printout or a static record does not preserve the dynamic record format that is part of the complete original record." FDA's example is the FT-IR spectral file, which "is dynamic and can be reprocessed"; a static printout of it "would not satisfy CGMP requirements to retain original records or true copies (§ 211.180(d))." MHRA's discussion of static retention is separate UK guidance and should not be read as relaxing that US position.

For UK medicines GMP, MHRA section 6.11.1 includes within the original record all subsequent data needed to reconstruct the GXP activity fully. For US drug CGMP, FDA Question 10 explains that a paper printout or static record may satisfy retention requirements when it is the original record or a true copy of that record. These are guidance statements, not a blanket rejection or acceptance of printouts.

For UK medicines GMP, MHRA section 6.11 discusses static retention where preservation of the original data’s integrity can be justified. For UK medicines GMP, that guidance expects verified copies of all raw data, metadata, relevant audit trails and result files, and record-specific variable software or system configuration settings. For UK medicines GMP, it also expects all processing runs needed to reconstruct the raw data set, including methods and audit trails.

A practical source-to-copy comparison can test the following dimensions rather than relying on appearance:

Document the comparison and any lost functionality. An attractive report, a signed PDF or a matching filename does not, by itself, demonstrate a true copy. Where the copy cannot support necessary review, retain the supporting source record rather than treating the report as its replacement. This applies ALCOA+ principles to the copying decision without assuming a universal certification method.

For UK medicines GMP, MHRA section 6.3 treats metadata as an integral part of the original record. The practical question is whether a reviewer can connect a reported result to the activity that produced it.

• Sample or batch identity connects the result to the material examined; units establish what the reported magnitude means.
• Acquisition time places the observation within the activity; actor identity identifies who performed it, or the source system for automated acquisition.
• Method version identifies the analytical or processing instructions used; source-file links connect reported results to their underlying observations.

These are illustrative context fields, not a universal mandatory schema. On the shop floor, production context tagging helps associate observations with manufacturing activity. Contextual fields describe the record and its origin; change history describes its evolution, as discussed next. Both can be metadata.

Relationship failures can leave readable files that are difficult to interpret. An orphaned attachment lacks a dependable parent-record link. An ambiguous identifier can point to different samples or batches. A timestamp without an identified event may mean acquisition, processing or export, obscuring sequence. Review the links as well as the displayed values; a populated field alone does not establish the relationship.

For EU medicinal-product GMP computerised systems, Annex 11 section 9 recommends considering system-generated audit trails for GMP-relevant changes and deletions through risk assessment. For EU medicinal-product GMP computerised systems, section 9 also expects audit trails to be available, convertible to a generally intelligible form and regularly reviewed.

Operationally, distinguish three kinds of evidence. A system audit trail records events affecting records; processing history connects data with the methods, settings and processing runs used to produce results. Review evidence identifies what somebody examined and concluded. These may overlap within an application, but the existence of a change log does not demonstrate that anyone assessed its significance.

A practical review sequence

1. Establish the record population: identify the batch, samples, equipment records and time window covered, including how the selection was made.
2. Connect relevant events to source data and processing versions. Follow identifiers rather than relying only on similar filenames or timestamps.
3. Examine reasons and effects: assess what changed, why it changed, and whether the change affected interpretation, attribution or the reported result.
4. Investigate unexplained events through the applicable deviation management process, preserving links to the affected records and documenting unresolved questions.
5. Document the review’s scope and conclusion, including exclusions, follow-up actions and the reviewer’s identity. An audit trail review workflow can structure this assessment.

For example, a reported concentration can remain numerically unchanged after reassignment to a different sample identifier or reprocessing with a different method version. The value alone would conceal the changed provenance or processing context. As a practical approach, set review timing and event coverage according to the record’s use and risk, rather than treating a completed checkbox or one universal schedule as sufficient.

For UK medicines GMP, MHRA section 6.17.1 expects archive arrangements to permit recovery and readability of data and metadata throughout the required retention period. Operationally, plan for future review, not merely storage capacity. Select retention durations for the applicable product and market rather than applying a single site-wide period without justification.

Build a retrievable retention package

Use a data integrity risk assessment to select the package contents. A practical package commonly brings together:

• Linked source content and the processing context needed to interpret results.
• Relevant change and processing history, with review evidence.
• An inventory identifying records, relationships, storage locations and responsible owners.
• Dependencies such as software versions, readers, configuration information and access arrangements.

These are risk-based implementation choices, not a universal file list. Identify which dependencies preserve meaning and which only support convenience. Refer to the static-copy assessment above when choosing retained representations.

Separate archiving from recovery

A backup is typically intended to restore data or systems after loss or failure; an archive is organised for long-term retrieval and interpretation. The technologies can overlap, but copied bytes alone do not demonstrate that a reviewer can open a record, follow its relationships or understand its results.

Practical lifecycle sequence: capture → review → prepare linked package → transfer to archive → test retrieval → maintain access → recover when needed.

Treat this sequence as an implementation aid, not a regulatory workflow. Representative retrieval tests can sample different record types, ages and dependencies. Check that output is readable, linked context remains accessible and analytical functions remain usable where relevant to later review. Record the test outcome and investigate access failures rather than accepting a successful file transfer as proof of usability.

Before system decommissioning, plan supported legacy readers or controlled migration. Test migrated records against their intended review uses, document any functionality lost and revisit the earlier static-copy assessment. Include both routine archive retrieval and recovery after disruption in the access strategy.

These hypothetical cases apply the distinctions above. Each disposition addresses a particular review question, not a blanket preference for electronic or paper records.

FT-IR identification

• Assumptions and units: The instrument stores a reprocessable spectral file, with wavenumber in inverse centimetres and dimensionless absorbance. Applying the classification above, this is the dynamic source record.
• Proposed representation: A fixed identification report presents the identification conclusion and a selected spectral plot rather than the complete spectrum and processing history.
• Review test: Can the reviewer assess whether the identification is supported across the acquired spectrum? Compare the report with the native file: the report omits spectral regions, processing context and the ability to reprocess. Those omissions matter when investigating an unexpected feature, even if the reported conclusion appears plausible.
• Justified disposition: Retain the usable spectral file with its associated processing context and the report. Treat the report as a review summary, not a substitute for the source spectrum in this case. This is a practical application of laboratory data integrity.

Balance ticket

• Assumptions and units: The balance has no persistent electronic measurement store. Its source result is a paper ticket recording mass in milligrams.
• Proposed representation: A scan would replace the retained paper ticket and link to the dispensing entry in the batch record.
• Review test: Check that the ticket identifies the measurement and connects it to the material, dispensing activity and operator. Compare the scan with the ticket for legibility, complete content, units and any annotations. Confirm that the dispensing link opens the correct image.
• Justified disposition: Keep the paper pending documented copy verification. Consider the scan for retention only after resolving identity, completeness and linkage gaps. This reasoning does not extend to balances that retain electronic measurements.

Mixing-temperature trend

• Assumptions and units: An electronic system stores temperature in degrees Celsius against elapsed time in minutes during mixing.
• Proposed representation: A PDF contains only a summary, without the underlying time series.
• Review test: Can the reviewer determine when an excursion occurred, how long it lasted and which mixing phase it affected? That question calls for the time series, sensor identity, batch association and time reference. Assume a transfer interval is missing from the receiving system.
• Justified disposition: Retain the source series and context; do not treat the summary as sufficient to resolve the excursion. Record the missing interval as an exception and follow the transfer-and-recovery approach in the recovery section.

Use this drug-focused map to identify the relevant instrument, not as a complete statement of current obligations. The format, metadata and retention explanations above inform record decisions; the distinction here is between binding rules and guidance.

For US finished pharmaceuticals, 21 CFR 211.180(c) requires records required under that part, or copies, to be readily available for authorised inspection during retention at the establishment where the activities occurred. For US finished pharmaceuticals under 21 CFR 211, the same paragraph treats records immediately retrievable electronically from another location as satisfying its availability condition.

For broader GMP record context, see records under 21 CFR 211. Manufacturers of supplements, food, devices and chemicals should check the current rules applicable to their own products and markets rather than importing this drug-focused mapping. Practical implementation choices and software support remain separate from the instruments listed here.

As an interface-design practice, distinguish delivery of a reported result from delivery of its source record and context. An instrument-to-LIMS message may carry a concentration and sample identifier without transferring the underlying acquisition files or processing history. A shop-floor-to-batch-record message may carry a completed step and final temperature without its process trend. Successful delivery demonstrates neither complete record transfer nor preservation of dynamic functionality.

For routine interfaces and data migration, define the intended transfer scope before testing completeness. In MES–historian interfaces, distinguish copied values from links to retained source records; test that those links resolve to the intended evidence.

A practical reconciliation set includes source_record_id, sample_id or batch_id, acquisition timestamp with time zone, units, method version, payload version and transfer status. These are illustrative controls, not a mandatory interface specification. A file inventory helps identify missing expected components; a checksum helps detect byte-level changes. Matching checksums do not establish semantic completeness: a faithfully copied package can still omit context or associate a result with the wrong batch. This distinction matters when assessing data integrity.

• Interrupted transfer: retain the source, isolate the incomplete delivery and reconcile received components against the intended package before controlled replay.
• Duplicate replay: compare source identifiers and prior acknowledgements; prevent another accepted result from being created merely because a message was resent.
• Mismatched identifiers: hold the affected transfer for investigation rather than silently substituting a plausible sample or batch.
• Orphaned metadata: preserve the unattached information and restore its relationship only after confirming the intended source record.

Record the exception, reconciliation, controlled replay where appropriate, and final disposition. Keep transport recovery separate from quality assessment: restoring delivery does not explain an unexplained process gap or establish that the laboratory or manufacturing activity was acceptable. Route unresolved evidence questions to the responsible reviewer.

Use this proposed checklist when selecting a retained format or changing an existing arrangement. Apply it to a defined record set and intended use, rather than approving a file extension in isolation.

1. Identify the source capture: instrument, application, paper entry or linked combination.
2. State the intended review question: what decision will this record support?
3. Identify necessary interactions: inspection, recalculation, reprocessing or trending, where relevant.
4. Map contextual fields and relationships, including identifiers, units, methods and linked records.
5. Compare the proposed copy with the source; record omissions and lost functionality.
6. Establish review scope: results, processing history, changes and exceptions relevant to the decision.
7. Reconcile transfers: account for expected records, rejected items, duplicates and unresolved exceptions.
8. Demonstrate retrieval: open retained records with their context using the planned access route.
9. Assign owners for intended use, technical access, recovery and documented assessment.
10. Document the decision, supporting checks, limitations and triggers for reassessment through change control.

Connect these checks to computerised system validation and the data integrity risk assessment. The process or data owner addresses intended use; the technical owner addresses access and recovery; designated reviewers document their assessment. Adapt job titles locally.

Distinguish control design from operation. A policy describes the planned control; completed reconciliation, review and retrieval records show what was checked, by whom, and with what result. Record unresolved limitations alongside the decision rather than treating the existence of a procedure as proof of execution.