Witnessing in the Embryology Lab: From a Name to an Event

There is a column on the embryology worksheet headed Witness. Under it, in most labs, is a name written in the same hand as everything else on the page, because the person filling in the sheet wrote both. Nobody involved is dishonest. The second embryologist was standing right there, watched the dish move, and went back to work while a colleague completed the paperwork. The witness happened. The evidence that it happened does not exist.

Witnessing is the control that stops the worst thing an ART lab can do, which is give the wrong material to the wrong person. It deserves better than a text field.

What witnessing is for

The lab handles material that is anonymous to the naked eye. A dish of oocytes looks like any other dish of oocytes. A straw looks like a straw. Identity travels entirely on labels, and labels are applied, read and transcribed by tired humans working under time pressure at a heated stage.

So at every point where material could be confused, a second person independently confirms identity before the step proceeds. The steps are well known: at retrieval, when oocytes are received from theatre; at insemination or injection, when eggs meet sperm; at denudation; at every change of dish; at freezing and at thawing; and above all at transfer, when material leaves the lab and enters a patient.

The last one deserves emphasis because it is where systems most often fall short. Embryo transfer is the highest-consequence identity step in the whole workflow, and it is the one where the witness record is most likely to be missing entirely rather than merely weak.

The four ways a witness field fails

A typed name fails predictably, and each failure has been found in real systems.

• It is not required. The field exists, the red asterisk is drawn in the markup, and the client-side check can be bypassed by anything that posts directly to the endpoint. The record saves with no witness at all.
• It is not authenticated. Any string is accepted. There is no check that the name belongs to a real person, still works there, or was anywhere near the lab that day.
• It permits self-witnessing. Nothing stops the operator entering their own name, and under pressure somebody eventually does.
• It can be edited afterwards. If the row can be updated, then what it says today is not evidence of what happened then.

There is a fifth, subtler failure. Some systems capture the witness properly at the interface, resolving the typed name to a real staff record with an identifier, and then save only the display text. The identity was in the browser's hands and was thrown away on the way to the database.

A witness you cannot authenticate, cannot verify was a second person, and can edit later is documentation, not a control.

Witnessing as an event

The alternative is to stop treating the witness as an attribute of a record and start treating it as an event in its own right.

An event has a subject: which specimen, identified by its own permanent identifier rather than by a description. It has a step: what was being done at that moment. It has two identities: the operator and the witness, both authenticated by whatever the lab uses to establish identity, which means a login or a badge scan and not a keyboard. It has a time, generated by the system rather than typed. And it is written once.

Write-once is the property that makes the rest worth having. If the witness event can be updated, everything above it is only as strong as the weakest person with edit rights. Labs that get this right enforce immutability in the database itself, so that no application path, no admin screen and no support script can quietly rewrite history. Corrections are made by adding a further event that says a correction was made, and by whom, which is how every other serious record-keeping discipline handles the same problem.

Electronic witnessing, and its honest limits

Barcode and RFID witnessing systems take the idea further. Every dish, tube and straw carries a machine-readable identity. A reader at the workstation knows what is present. If two items belonging to different patients are on the stage at once, the system stops the step rather than recording that it happened.

That hard stop is the real advance. A human witness confirms that the labels match; an electronic system can refuse to let the work proceed when they do not. Removing the possibility beats detecting the error.

The limits are worth stating plainly, because vendors rarely do.

• It witnesses labels, not biology. If the wrong label went on at the start, the system faithfully confirms the wrong thing all the way through.
• It only covers steps where readers are actually deployed. Coverage in the andrology room and at the tanks is commonly thinner than in the main lab.
• It is only as good as its exception path. Every lab has moments when the reader fails, and how the system handles a manual override, whether it demands a reason, and whether it flags the override for review, determines whether the control survives a busy Monday.
• It generates data nobody reads unless somebody looks. Override rates and refused steps are the most useful quality signal the lab produces, and in most labs nobody has ever run that report.

Electronic witnessing is a strong control. It is not a reason to stop thinking about identity.

What it costs and what it buys

The objection is always time. Two people, at every step, in a lab that is already stretched on a heavy retrieval morning. That objection is legitimate and should be answered honestly: witnessing does cost time, and a design that pretends otherwise gets circumvented.

What it buys is the ability to answer questions that cannot be answered any other way. Who was present when this embryo was frozen. Whether the transfer on the fourteenth was independently confirmed. Whether the same two people witness for each other every single time, which is a rota problem worth knowing about. And, in the worst case, whether the clinic can demonstrate that its controls were operating on the day something went wrong.

That last point is what makes this a management question rather than a lab question. A clinic with immutable witness events can investigate an incident. A clinic with a name column can only apologise.

A short audit you can run this week

You do not need a project to find out where you stand.

• Take last month's freezes and transfers. For each, is there a witness record, and does it name somebody other than the operator?
• Post a record directly to the endpoint with the witness field empty. Does the server accept it?
• Change a witness name on a record from six months ago. Can you? Does anything notice?
• Count how often each pair of staff witnesses for each other. If two names account for most of the lab, that is a single point of failure wearing the appearance of a control.
• Ask the lab what they do when the barcode reader fails, and compare the answer to what the system actually permits.

Most labs already do the witnessing. What they lack is proof, and proof is the part that only matters once.