SOP: Metadata Governance and Preservation Across GxP Systems

This is a ready-to-use SOP for governing metadata as data moves within and between GxP systems. Metadata, the contextual information that makes a result meaningful (who, when, with what instrument, under what method, with what processing), is part of the record, not supplementary documentation to it. This procedure defines what counts as metadata for a given record type, names which system is authoritative for each metadata field, and requires a documented, verified mapping for every interface a record crosses, so metadata is a governed asset instead of whatever happens to survive a given export. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows. Verify each cited regulation against the current source before you rely on it, and treat this as general guidance to adapt rather than legal or regulatory advice.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> identifies GxP metadata, assigns ownership and authority for it, and preserves it as data moves within a system, between systems, and into an archive. The objective is that metadata required to understand, attribute, and reconstruct a GxP record survives every hop that record makes, and that when two systems disagree about a value, there is a defined answer for which one governs.

2. Scope

This procedure applies to metadata associated with GxP records held in laboratory systems (chromatography data systems, LIMS, electronic laboratory notebooks), manufacturing systems (MES, electronic batch records, SCADA, process historians), and business systems that hold or display GxP-relevant data (ERP quality modules, document management systems). It covers metadata definition per record type, ownership assignment, interface mapping and verification, and preservation through migration and archival. It does not itself define the retention period for the records the metadata describes, which is set by <<FILL: records retention SOP-ID>>, or the technical qualification of an interface, which is addressed by the relevant system’s validation documentation.

3. Responsibilities

4. Definitions

• Metadata: the contextual information required to understand data, including but not limited to user or operator identity, date and time of acquisition or action, instrument or system identifier, method or software version, processing parameters, and links to the batch, sample, subject, or study the data belongs to.
• Authoritative system: for a given metadata field, the system whose value governs when two systems disagree. Every field in scope has exactly one authoritative system at any point in time.
• Metadata mapping: a field-by-field specification stating, for an interface between two systems, which fields transfer, any transformation applied, and which fields do not transfer at all.
• Interface: any mechanism, validated electronic connection, scripted export/import, or manual transcription, by which data or metadata moves from one system to another.
• Metadata loss: any case where a field present in the source system is absent, truncated, or altered without a documented, justified transformation on arrival at the target system.

5. Procedure

5.1 Define the metadata taxonomy per record type

1. For each GxP record type in scope, list the metadata fields required to understand, attribute, and reconstruct the record: attribution, temporal, instrument/system, processing, context (batch/sample/subject links), and audit trail, at minimum.
2. Approve the taxonomy through Quality Assurance and reference it in the record type’s raw data definition.

5.2 Assign the authoritative system per field

1. For each metadata field, identify every system that holds or displays it across its lifecycle.
2. Name exactly one authoritative system per field, normally the system that first generates the field (for example, the chromatography data system for integration parameters, the historian for a sensor tag’s engineering unit and scaling).
3. Document the assignment in the interface mapping (section 5.3) and in the system inventory entry for each system involved.
4. Where a downstream system needs to display a field it does not govern, mark that display as derived, not authoritative, so a discrepancy is investigated against the source rather than the display.

5.3 Build and verify the interface mapping

1. For every interface a record crosses, produce a field-by-field mapping: source field, target field, transformation applied (if any), and whether the field transfers at all.
2. Explicitly flag fields present at the source that do not transfer to the target. A blank in the mapping is not acceptable; state “does not transfer” and the reason.
3. Verify the mapping by testing real or representative records across the interface and confirming each field lands as specified. Use the interface data mapping verification form to record this.
4. Approve the mapping through Quality Assurance before the interface goes live for GxP use.
5. Re-verify the mapping after any change to either system that could affect the fields in scope (version upgrade, configuration change, re-platforming).

5.4 Preserve metadata through migration and archival

1. Treat metadata as part of the record set for any data migration; do not scope a migration around result values alone.
2. Confirm the migration or archival plan explicitly carries audit trail entries, timestamps, and attribution alongside the primary data, per <<FILL: migration validation SOP-ID / data migration validation protocol>>.
3. Where an archive cannot preserve a field in its original form (for example, a discontinued application’s proprietary metadata structure), document the loss, the justification, and the QA-approved acceptance of that loss before the source is retired.

5.5 Monitor for drift

1. On a periodic basis, sample records that have crossed a governed interface and confirm the metadata still matches the mapping.
2. Investigate any drift (a field that used to transfer and no longer does, or a value that no longer matches the authoritative source) as a potential unauthorized change to the interface.

6. Acceptance criteria

• Every GxP record type in scope has an approved metadata taxonomy.
• Every metadata field has exactly one named authoritative system.
• Every interface a governed record crosses has an approved, verified field-by-field mapping, with fields that do not transfer explicitly stated.
• Migration and archival plans preserve metadata alongside primary data, with any unavoidable loss documented and approved before the source is retired.
• Periodic monitoring has been performed and any drift investigated.

7. References

FDA guidance, Data Integrity and Compliance With Drug CGMP, Questions and Answers (December 2018), definition of metadata as the contextual information required to understand data. 21 CFR 211.194 (laboratory records) and 211.180 (general records requirements). 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (Computerised Systems) and EU GMP Chapter 4 (Documentation). MHRA GxP Data Integrity Guidance and Definitions (March 2018). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments.

Confirm the current version and clause numbers of each reference before issue.

8. Revision history

9. Approvals

Filled specimen

The following shows the metadata taxonomy and authority assignment completed for an example finished-product assay result moving from a chromatography data system through a LIMS into an ERP quality module, so you can see the level of detail an inspector expects. The company and system names are illustrative.

Metadata taxonomy for “finished-product HPLC assay result” (specimen)

Interface mapping verification (specimen)

The value of this specimen is in what it makes explicit: the ERP module shows a clean pass/fail line for the batch, and without this mapping a reviewer might assume that line carries the same evidentiary weight as the CDS result. Documenting that instrument ID, method version, and integration parameters stop at LIMS means an investigator or an internal reviewer knows to go back to the CDS for those fields rather than treating their absence in ERP as data loss.

Common inspection findings this SOP prevents

• A downstream system’s summary value is treated as equivalent to the source record, and a data integrity question cannot be answered from it because the metadata never transferred.
• Two systems display different values for the same field with no documented authority to resolve the disagreement.
• An interface change (upgrade, reconfiguration) silently altered what metadata transfers, and nobody re-verified the mapping.
• A migration carried result values but not the audit trail or instrument metadata behind them.
• Metadata fields needed to reconstruct a result are known to exist in one system but nobody can say whether they were expected to appear in another.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Build the taxonomy in section 5.1 from your actual highest-risk record types first (release testing, batch disposition), then extend.
3. Use the interface data mapping verification form as the working document for section 5.3; reference its number here rather than duplicating its content.
4. Point the cross-reference in section 5.4 at your actual migration validation procedure or protocol.
5. Confirm every regulation in section 7 against the current published version before issue.