Guide · Updated 2026
What an auditor wants to see when a file moves
Regulated laboratories are expected to keep an audit trail for data and for second-person review. Most of that expectation is met inside the instrument software and the LIMS. The gap is the space between them: the moment a file is carried from one system to another.
Written by Taha Bayar, a biologist working on laboratory data handover. Kionel sells one of the options below. The checklist works whichever route you choose.
The question, in one line
Who moved which file, when, and can you show that what arrived is what left? Everything below is a way of answering that sentence, or failing to.
What a transfer record should contain
| Element | Why an inspector asks for it |
|---|---|
| Identity of the file | A name is not enough; two files can share a name. A content hash identifies the bytes. |
| Who released it | An account, a key or a signature — something that ties the action to a person or a controlled credential. |
| Who received it | A one-sided record is a claim, not a handover. |
| When | A time that both sides agree on, and whose source is stated. A device clock is a device clock. |
| Integrity on arrival | Evidence that the received copy matches the released one, not just that a copy appeared. |
| Where it is kept | A record that lives only on the instrument PC disappears with the instrument PC. |
Why the usual routes struggle
- USB stick. The transfer itself leaves nothing behind. Sites compensate with a paper logbook, which records intent rather than the event, and which nobody can tie to a specific file.
- Shared folder or network drive. Better, if the file system keeps access logs and someone retains them. Often the log is overwritten, or shows a service account rather than a person.
- Email. Produces a trail of sorts, but usually outside the quality system, and frequently outside policy for laboratory data.
- Printing and re-keying. Creates a clean paper record and a transcription risk; needs its own second-person check.
- Data diode. Strong for continuous flows between networks. Whether an individual handover is recorded depends on what you put on each end.
None of these is wrong. The point is that the record is a separate thing from the movement, and if nobody designed it, it does not exist.
A practical checklist
Name the step
Write down exactly which handover you are talking about: from which system, to which system, how often, which file types.
Decide what proves it
Hash, sender, receiver, time, integrity result. Decide before choosing a tool, or the tool decides for you.
Decide where the proof lives
In the LIMS? Next to the result? In a quality folder? A record nobody can find is not a record.
Decide who checks it
Second-person review applies to the handover too, not only to the result.
Test the failure case
Corrupt a file on purpose and confirm your process notices. A control that has never failed has never been tested.
Where Kionel fits
Kionel produces that record as part of the movement instead of beside it: the sender signs a dispatch record over the content hash, the receiver verifies the content and signs a delivery record. Both verify offline, with a tool that stays free under Apache-2.0, so the evidence outlives the supplier.
It is for small files and it needs a site that permits screens and cameras. It does not scan file content, and it does not replace your validation work. The limits page is the full list.