A useful laboratory record should allow someone who was absent from the work to understand it later. That sounds straightforward until cleaning records, instrument checks, sample results and maintenance reports are held in different places.

The challenge is connecting those records into a reliable account of what happened. For a cosmetic laboratory, that account can support routine handovers, investigations and decisions about whether equipment or results are suitable for their intended use.

Great Britain’s cosmetics guidance includes current documentation covering manufacturing, quality control, storage and shipment among its practical GMP expectations. The workflow below offers a way to organise laboratory evidence around that purpose.

Connect the activity, the item and the person

The W3C provenance model describes relationships between things, activities and responsible people or systems. That is a useful design principle for laboratory records.

For each activity, identify the equipment, area, sample or material involved. Connect it to the procedure used, the observations produced and the person responsible. Use stable identifiers so that two similar instruments cannot easily be confused.

Keep the relevant procedure revision with the record or preserve a reliable link to it. A link that always opens today’s procedure may leave a reviewer unable to establish what instructions applied six months ago.

These are proposed record-design choices. The laboratory should decide which relationships matter for its work.

Give each timestamp a clear meaning

A single “date completed” field can hide several different events. Consider distinguishing:

  • Activity time: When the work or observation occurred.
  • Entry time: When the information was first recorded in the system.
  • Review time: When an identified person evaluated the record.
  • Decision time: When a restriction, approval or return-to-use decision took effect.

These times may coincide. When they differ, the difference should remain understandable.

In an illustrative example, a technician completes a temperature check at 09:10, enters the observation at 09:25 and receives a review at 10:00. A system that displays only 10:00 could create confusion about when the condition was observed.

Capture information when the work occurs wherever practicable. If an entry is delayed, identify that fact and retain the original observation according to the laboratory’s procedure. An automatically generated timestamp establishes a system event. It does not independently establish when a person performed a physical task.

Preserve corrections and their consequences

Corrections are part of an honest record. A useful correction process preserves the previous information, identifies the person making the change and records the reason.

For example, an analyst may discover that an instrument identifier was entered incorrectly. Changing the identifier should leave a visible explanation and supporting basis. If the correction changes which equipment history applies, the reviewer should consider whether an earlier decision needs reassessment.

Avoid collecting a reason merely to satisfy a required field. “Correction” explains very little. A short, specific explanation can tell the next reviewer what was wrong and how the corrected information was established.

Distinguish completion from acceptance

A task can be performed while its outcome still needs attention.

A cleaning activity may be complete with a residue observation awaiting follow-up. Maintenance may be finished while a post-service check remains outstanding. A result may be entered while its review is pending.

Define statuses in language that tells people what they may do next. “Work performed”, “awaiting review”, “restricted from use” and “ready for use” can serve different purposes. Specify who can change each status and what evidence supports the change.

Where the workflow permits one person to perform and review an activity, retain the meaning of each action. Do not create an apparent second-person review from an automatic system update.

Test the software with an actual record

When evaluating digital tools, ask for a demonstration using a realistic laboratory scenario.

Can the system retain the original entry and its corrections? Can someone find the applicable procedure revision? Can a reviewer see an unresolved issue without searching another application? Are imported measurements distinguishable from manually entered values?

Check how individual users are identified, how access is controlled and how records remain available when someone leaves the team. Test whether an export preserves understandable history, attachments and relationships.

Features should be assessed in the way the laboratory will configure and use them. A product’s “audit trail” label alone does not establish what events it records or who can alter its history.

Practise reconstructing one piece of work

Choose a completed test and ask a colleague to identify the sample, instrument, relevant checks, analyst, procedure and review decision. Include any linked exception or service activity.

Note every point where reconstruction depends on memory or an unrecorded assumption. Those gaps provide a focused improvement list.

Well-organised paper records can support this exercise too. The practical goal is a record that remains understandable across staff changes and the passage of time, with enough context to support the next decision.

Sources: GB cosmetics guidance; W3C provenance model primer.