Metadata: the part of the record that makes the number mean something

Take one line from a deviation investigation: 23 (08/02) 02:30. Before anyone can ask whether the product was affected, three questions need answering. Twenty-three what: degrees, millibar, milligrams? The 8th of February or the 2nd of August? And which 02:30, if the clocks went back that night and the hour happened twice? (The line is made up. The questions come up all the time.)

None of them is about fraud. They are about metadata, the context stored with a value that says what it is, where it came from, when it was taken and what has happened to it since. On plants and in laboratories most metadata failures are ordinary engineering slips: a unit missing from a tag, a clock that drifted, an export that dropped the audit trail. They are also what turns a perfectly correct value into one nobody can defend.

What the regulators mean by metadata

The main data integrity guidances agree. The US Food and Drug Administration (FDA) calls metadata “the contextual information required to understand data”, and uses the number 23 as its example: meaningless without the unit “mg” (Data Integrity Q&A, 2018, question 1.b). The UK Medicines and Healthcare products Regulatory Agency (MHRA) says metadata “form an integral part of the original record” and that without them “the data has no meaning” (2018, §6.3). The European Medicines Agency (EMA) lists the usual items: variable name, unit, value before and after a change, reason for change, timestamp, user (2023, §4.3).

Two consequences follow for anyone who configures or validates a system. First, a value copied without its metadata is no longer the record; the FDA asks that the relationships between data and their metadata be “preserved in a secure and traceable manner”. Second, metadata have to be designed in. A system stores only the context it was configured to store, and adding a missing unit or time zone afterwards always raises a new question.

Four failures that have nothing to do with fraud

The first is the unit. A historian tag configured without an engineering unit displays “23” and leaves the reader to fill in the rest. Pressure in millibar read as bar, a concentration in mg/mL read as mg/L: the value is right and the conclusion wrong. Interfaces make it worse, because each system assumes its own unit. OPC Unified Architecture (OPC UA, IEC 62541), the common industrial interface standard, carries an EngineeringUnits property with every analogue value, provided someone fills it in. The most famous unit failure is not even pharmaceutical: NASA lost the Mars Climate Orbiter in 1999 because a ground file gave thruster data in pound-force seconds where newton-seconds were expected.

Then dates. 08/02/2019 is 2 August in the US format (mm/dd/yyyy) and 8 February in the British one (dd/mm/yyyy). The date format is metadata, and when it is left implicit the value is ambiguous. PIC/S asks for date fields in “an unambiguous format defined for the site” (PI 041-1, 2021). For anything that leaves a system (exports, interfaces, spreadsheets) we recommend the ISO 8601 order, year first: 2019-02-08. It sorts correctly, and nobody reads it backwards.

Time is the third. A timestamp without a time zone is only half a timestamp. In the EU, summer time ends at 01:00 UTC on the last Sunday of October (Directive 2000/84/EC). On Central European Time, local clocks that night run from 02:00 to 02:59 twice: on 26 October 2025, an event logged at “02:30” may be 00:30 UTC or 01:30 UTC. In March the same hour does not exist at all. Systems that store local time without an offset get a duplicate hour or a missing one in trends and batch records twice a year. ISO 8601 solves it by carrying the offset: 2025-10-26T02:30+02:00 and 2025-10-26T02:30+01:00 are two different moments. Store UTC, or local time with its offset, and convert only for display.

Clocks also drift. A programmable logic controller (PLC) or a stand-alone instrument nobody has synchronised for a year can be minutes out, and its events then sit in the wrong order against the rest of the plant. The MHRA expects “appropriately controlled/synchronised clocks” and a specified time zone when data are used across sites (§5.1). Synchronising every device to a site time source, with Network Time Protocol (NTP) or Precision Time Protocol (PTP) where finer precision is needed, is the network’s job; checking that each device actually follows it is part of qualification.

The last is copies. An export to CSV or PDF keeps the numbers and drops the rest: the audit trail, the status of the result, sometimes the unit. The FDA accepts a printout when it is the original or a true copy, but not for dynamic records such as an infrared spectrum that can be reprocessed (Q&A, question 10). The MHRA defines a true copy as one verified to have “the same information, including data that describe the context, content, and structure, as the original” (§6.11). Strip the metadata and the copy is no longer true.

Where metadata gets lost: acquire, store, process, report

Every information system does four things with data: it acquires, stores, processes and reports it. Each step creates metadata and each can lose it, so the four steps make a workable map of risk. It is the same ground the MHRA covers as the data lifecycle (§6.6).

Two steps get less attention than they deserve. Migration to a new system is when units, time zones and tag descriptions are most often mapped wrongly, which is why Annex 11 asks validation to check that data are not altered “in value and/or meaning” (§4.8). Reporting is where exports, averages and interpolated values appear, and where spreadsheets begin an unvalidated life of their own.

ALCOA+ is a list of metadata requirements

ALCOA (attributable, legible, contemporaneous, original, accurate) began as a memory aid coined by an FDA official in the early 1990s. The four “plus” attributes (complete, consistent, enduring, available) appeared in an EMA reflection paper on clinical trial data in 2010, and later in GMP guidance from the MHRA (2018) and PIC/S (2021). Read letter by letter, nearly every principle turns out to be a demand for a particular piece of metadata. Attributable needs a unique user ID and an audit trail of every entry, change and deletion. Contemporaneous needs a timestamp you can trust. Accurate needs corrections that leave the original readable, dated and explained, which EU GMP Chapter 4 asks of any document (§4.9) and Part 11 of electronic records: “Record changes shall not obscure previously recorded information” (21 CFR 11.10(e)).

The table below restates the usual ALCOA+ table in neutral terms and adds the metadata that carries each principle. Take the definitions from the regulators rather than from product brochures; PIC/S PI 041-1 (§7.5) even lists date formats, units of measurement, rounding and significant digits under consistent. The EMA clinical trials guideline adds a tenth principle, traceable (ALCOA++).

ALCOA+ describes the record. The behaviour of people (shared logins, deleted injections, back-dated entries) is another matter, covered in our article on recurring inspection findings. The signature is a subject of its own too: the printed name, the date and time, and the meaning of the signature all belong to the record it signs.

Write it into the URS, test it in OQ

Metadata requirements are cheapest at specification time. For each GxP record a system produces, we write four things into the user requirements specification (URS). The mandatory context: unit, source ID, user or system ID, timestamp with time zone, method or recipe version, status, and a reason for every change. The time base: UTC or local time with offset, the synchronisation source, who may change the clock and what the audit trail records when someone does. The formats that leave the system: ISO 8601 dates, units in column headers, the decimal separator, the rounding rule. And the copy route, meaning how a true copy is produced, with which metadata, and how a reader can tell it is a copy.

Then we test them in operational qualification (OQ), with tests designed to fail when the metadata fail:

1. Change the system clock with an administrator account and look for the audit trail entry.
2. Simulate the October clock change on a test system and check trends, reports and sort order.
3. Export a record and compare every field (value, unit, timestamp, status, audit trail reference) with the source.
4. Migrate a sample of records and verify value and meaning, not just the record count.
5. Edit a value and check that the old value, the new value, the user, the time and the reason are all recorded.

Older systems will not manage all of this, and that is no reason to stop. Where an instrument stamps local time with no offset, or a controller holds no unit, fix the context at the boundary: state the unit and the time base in the report template and the system description, and check them at each periodic review. The MHRA accepts equivalent control by other means where a system cannot provide it, “justified and documented” (§6.16). We apply the same reasoning to missing context: name the gap, name the compensating control, and review it.

In routine operation, the periodic review adds two quick checks: the offset of each system clock against the reference, and the list of tag or configuration changes since the last review.

The mistakes we see most often

Units that live in the operator’s head come top. The HMI shows “23”; everyone on the line knows it is millibar, and nobody in QA does. Time zones set by the installer are a close second: a server configured in another country keeps its factory time zone, and the offset only surfaces in the first cross-site investigation.

• Clock rights for everyone. A user who can change the workstation clock can change the contemporaneous record.
• Migration validated by record count. 100,000 records sent and 100,000 received tells you nothing about whether the unit column came with them.
• The PDF as the archive. Keep the report and delete the dynamic data file, and you have kept the number and lost the record.

Anyone can copy the value. The metadata is what lets you prove it.

References

• US FDA, Data Integrity and Compliance With Drug CGMP: Questions and Answers, December 2018, questions 1.b and 10, fda.gov
• MHRA, ‘GXP’ Data Integrity Guidance and Definitions, revision 1, March 2018, §5.1, §6.3, §6.6, §6.11, §6.16, gov.uk
• PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, 1 July 2021, §7.5, picscheme.org
• EudraLex Volume 4, EU GMP Annex 11 Computerised Systems (2011), §4.8 and §6, health.ec.europa.eu
• Directive 2000/84/EC of 19 January 2001 on summer-time arrangements, Articles 2 and 3, eur-lex.europa.eu