Begin with one decision
Choose a concrete example: a result was corrected, an equipment requirement changed or supporting evidence was replaced. Ask what a later reviewer would need to understand that decision.
For an original evaluation framework, consider four layers:
| Layer | Question |
|---|---|
| Source record | What information was recorded? |
| Change history | What changed, when and through which action or account? |
| Supporting evidence | What information supported the change or decision? |
| Authorised decision | Who had responsibility to accept the outcome under the laboratory’s procedure? |
A log may help with one or more layers. Do not assume it covers all four.
Test the exact change that matters
Create a synthetic record, change a meaningful field and ask another evaluator to reconstruct the sequence. Repeat the test for an attachment replacement or status change if those are important to the proposed use.
Check whether the previous value is retained, whether the reason is captured where your procedure needs one and whether the event is connected to the correct record. Mark an untested action as untested. A demonstration of one field change does not prove coverage of every administrative or bulk operation.
Separate an account event from a complete explanation
An account identifier and timestamp can be useful evidence, but they do not by themselves explain why a change was scientifically appropriate or whether the person had the relevant authority. Ask how account permissions, approval responsibilities and supporting records are managed.
For systems handling personal information, access and information-security controls require their own assessment. The OAIC’s security guidance is a relevant reference where applicable. A history screen is not a substitute for that assessment.
Ask about the boundaries of the history
Useful supplier questions include how long relevant events are retained, how authorised people retrieve them and what happens when an item is archived. Ask whether exports include the history needed for the agreed purpose. Do not assume that viewing a log on screen guarantees a usable exit record.
Also ask which actions are outside the history. A precise answer about limitations is more useful than an unsupported claim of complete or immutable logging.
Keep accreditation separate
NATA accreditation concerns assessment of an organisation’s competence for its specified activities; it is not a certification automatically transferred by software. The NATA accreditation overview explains that context. The ISO/IEC 17025 public overview describes laboratory competence, impartiality and consistent operation.
Software-supported evidence can contribute to a laboratory’s processes. It does not establish, on its own, that those processes meet all applicable requirements or that the scientific conclusion was correct.
Use a traceability exercise, not a badge
Give an evaluator one synthetic equipment or sample identifier. Ask them to find the relevant event, the reason for a change, the supporting evidence and the final decision. Observe where they need help and what cannot be retrieved.
Record those gaps in plain language. “The previous attachment could not be located” is more useful than “audit trail needs improvement”. Decide which gaps matter for the intended use, which require a different process and which prevent proceeding.
A useful record history makes important events understandable. Its value comes from the specific questions it can answer—and an honest account of the ones it cannot.
Review the current scope of AureqoLab and AureqoEq, then bring one traceability question to a Request a product walkthrough.