Instrument time synchronisation: chronology and audit trails

An acquisition appears to occur after its review. An injection seems earlier than the one listed first in the sequence. Before concluding that someone changed the data, establish what the clocks involved measure and how the systems present time.

Laboratory chronology crosses instruments, workstations, applications, databases and interfaces. Different timestamps may describe one instant in different zones or different events, such as acquisition and receipt. The aim is a verifiable sequence that preserves original data, context and any remaining uncertainty.

1. Identify who generates each timestamp

For each relevant event, identify the system assigning its date and time. Software may use the operating-system clock, the instrument clock or a central service: verifying this is part of understanding the system. The database may record another moment, distinct from the scientific event.

Distinguish acquisition start, saving, interface receipt, import, processing and approval. A file modification date alone does not prove when the sample was analysed. Transmission delay does not necessarily mean clock drift.

Instrument–LIMS reconciliation must also preserve these meanings: a column called “date” does not establish which event it represents.

2. Separate instant, time zone and display

UTC provides a common reference. Local time requires its UTC offset and, when necessary, the time-zone rules applied. “02:30” without a date and context may be ambiguous, particularly when daylight saving ends.

UTC storage and local display are technical choices to verify in the product. Do not assume displayed time is stored time. Check screens, exports and audit trails, including offset signs, precision and fractions of seconds. The format must preserve meaning during transfers.

RFC 3339 describes offsets as local time minus UTC. To recover UTC, subtract the stated offset. Alphabetical timestamp sorting is not automatically chronological when representations or offsets differ. Time-zone rules change: identify dependencies on the time-zone database used.

3. Build the time map

This matrix is an investigation example, not a prescribed architecture. Complete it using documented behaviour and observed evidence. Clarify unknown fields before relying on the timestamp for a critical decision.

Assign responsibility for maintaining this map when workstations are replaced, applications updated or interfaces changed. A valid server setting does not automatically establish the setting of every connected device.

4. Define sources, criteria and tests

Establish authorised time sources, configuration responsibilities and change privileges. NTP distributes a time reference; using the protocol alone does not demonstrate correctness, availability or protection of the configuration. Provide for observing offsets and loss of synchronisation.

Criteria depend on the process: resolving closely spaced events may require different precision from recording a daily review. Justify tolerance, comparison frequency and alarm response using data granularity, potential drift and consequences. There is no universal threshold in seconds here.

In a separate authorised environment, test relevant source loss, communication restoration, time-zone changes and daylight-saving transitions. Verify that events remain interpretable and anomalies are detected. Record the condition tested, expected and observed results, and exceptions; do not change the production clock to create a test.

5. Simulated case: local time appears to go backwards

Assume an offset change within the same day: event A is recorded at 02:55 with +02:00; event B at 02:10 with +01:00. In UTC, A is 00:55 and B is 01:10. B therefore occurs 15 minutes after A despite showing an earlier local time.

Supporting this reconstruction requires the complete date, offsets actually associated with the events, identifiers, clock origins and display rules. Knowing that “the clocks change around then” is insufficient. If the offset is absent, preserve the ambiguity and seek independent evidence, such as sequence order and related records, assessing their reliability too.

The conversion belongs in the documented reconstruction; it does not replace original timestamps. A normalised working copy must identify its source, transformation and link to the retained record.

6. Manage anomalies without rewriting history

If a clock is corrected, record its previous and new values, reason, authorisation and potentially affected interval according to the system and procedure. Assess effects on sequences, signatures, imports and results already used. A correction may create apparent jumps or overlaps: do not retrospectively “repair” records to make them look ordered.

CDS audit-trail review must distinguish time error, process delay and actual modification. If order remains uncertain, document that limitation and the impact decision; avoid a chronology that only appears precise.

Sources and status — checked 2 October 2026. EU GMP Annex 11, January 2011 revision, §§9 and 12.4; 21 CFR Part 11, §11.10(e), within applicable scope. Technical references, without prescribing a universal GMP configuration: RFC 3339, July 2002, offset semantics; updated by RFC 9557; IANA Time Zone Database, online resource; PTB NTP technical guidance; NIST SP 800-53 Rev. 5, September 2020, December 2020 update, controls AU-8 and SC-45. Matrix and case are original editorial examples.