Kōami
Back to Resources
Operations6 min read

NABL for a Hospital Lab: What the Software Has to Prove

K

Kōami

Editorial team

Share this article
NABL for a Hospital Lab: What the Software Has to Prove — Operations | Kōami

Six weeks before the assessment, the lab in-charge starts a spreadsheet. It has tabs for equipment calibration, internal quality control, competency records, and a list of every result that went out amended. Most of the data exists somewhere. Some of it is in the analyser, some in a register on the bench, some in a WhatsApp thread where a technologist reported an out-of-range control at eleven at night. The spreadsheet is an act of archaeology, and it will be redone from scratch before the next assessment.

NABL accreditation for a medical laboratory is built on ISO 15189, and the standard's demand is not that a lab be excellent on the day of the assessment. It is that the lab can demonstrate it was in control on any day. That is a records question, and it is where laboratory software either helps or quietly gets in the way.

The evidence a lab has to produce

Strip away the vocabulary and an assessment asks a lab to demonstrate a handful of things, repeatedly, across different tests and different days.

  • That the sample which produced this result is the sample that was collected from this patient.
  • That the instrument was in control when the result was produced.
  • That the person who performed and released it was competent to do so.
  • That the result reached the right clinician in the right time, and that critical results reached them faster.
  • That when something went wrong, it was recorded, investigated and closed.
  • That the reference intervals, methods and units on the report are the ones the lab validated.

Each of these is a chain of evidence. Where a link lives on paper or in an analyser's local memory, assembling the chain is manual, and manual assembly is what turns preparation into a six-week project.

The pre-analytical phase, where most errors actually happen

Laboratory quality literature is consistent on this: the majority of errors occur before the sample reaches the analyser. Wrong patient, wrong tube, insufficient volume, haemolysis, delay in transport, wrong preservative.

Software earns its place here more than anywhere else.

Positive identification at collection, with the label printed at the patient's side rather than pre-printed and carried, closes the most dangerous gap in the process. A pre-printed label that travels to a bedside is an accident with a delay built in.

Sample lifecycle timestamps — collected, received, accepted or rejected, run, verified, reported — turn turnaround time from an estimate into a measurement, and turnaround is one of the things a lab must monitor.

Structured rejection reasons matter more than they look. If rejections are recorded as free text, the lab cannot tell whether haemolysis is rising in one ward, which is exactly the kind of finding that leads to a real improvement.

The lab that can say "twelve percent of our rejections come from one ward, and here is what we did about it" is demonstrating a quality system. The lab with a rejection register nobody totals is demonstrating a register.

Quality control that is recorded when it happens

Internal quality control is the heart of an assessment and the commonest place preparation falls apart.

Control results should be captured as data, with the lot number, the level, the analyser, the operator and the time. Levey-Jennings charts should be drawn from that data rather than maintained separately, because a chart maintained by hand is a chart drawn after the fact.

Westgard rule violations need to be flagged, and, crucially, what happened next needs to be recorded against the violation: what was investigated, what corrective action was taken, whether patient results in the affected window were reviewed and recalled. An assessor's follow-up question is almost never "do you run controls". It is "show me a violation and what you did about it".

External quality assessment participation, results and any corrective actions belong in the same place, along with the evidence that unsatisfactory performance was investigated rather than filed.

The pattern across all of this is the same: it is not the doing that is hard, it is the proving. Labs run controls diligently. They struggle to show, two years later, what happened on the day one failed.

Competency, calibration and the records that expire

Two categories of record share a property that makes them ideal for software: they expire.

Staff competency records include initial training, assessment, periodic reassessment, and authorisation to release results for particular tests. A technologist authorised to release biochemistry is not automatically authorised to release histopathology, and the system should know the difference rather than relying on a role called Lab.

Equipment records cover calibration, maintenance, service history, temperature monitoring for storage, and validation after repair. Each has a due date.

Anything with an expiry date should generate a reminder before it expires and an escalation when it lapses. This is unglamorous automation and it removes an entire class of assessment finding, because most lapses are not negligence. They are a date nobody was tracking.

Reporting, amendments and the honest audit trail

The report is the lab's product, and it carries requirements that are easy to get wrong.

It has to identify the patient unambiguously, state the method where the method matters, carry reference intervals appropriate to the patient's age and sex, use the units the lab validated, and be released by an authorised person whose identity is recorded.

Amendments are where the audit trail earns its keep. When a result is corrected after release, the original must remain visible, the amendment must be marked as such, the reason must be recorded, and there must be evidence that the clinician who received the original was informed. A system that lets a result be silently overwritten has destroyed exactly the record an assessment wants to see, and has created a clinical risk on the way.

Critical result communication needs the same treatment: the value, who was called, when, who took the call, and what was read back. A note saying "informed" is not evidence. It is a claim.

Preparing without the six-week scramble

The lab that finds assessment easy is the one where the evidence is a by-product of the work rather than a separate exercise.

  • Capture control data in the system as it is run, not on a sheet to be entered later.
  • Record corrective actions against the violation that triggered them, so the two are permanently linked.
  • Put every expiring record — competency, calibration, reagent lot, service — on a reminder with an escalation.
  • Structure sample rejection reasons and review the totals monthly.
  • Log critical result communication as a structured event with the read-back.
  • Make amendments additive, never destructive, with a mandatory reason.
  • Run the reports an assessor would ask for, once a quarter, on an ordinary week. If a report takes two days to produce, that is the finding, and you have found it yourself.

Accreditation is often described as a burden, and the paperwork is real. But almost every item on the list above is something a lab wants anyway: knowing which ward sends haemolysed samples, which analyser drifts, which reagent lot underperformed, which results were amended and why. The accreditation just insists you write it down.

Found this useful? Pass it on to someone on your team.

Share this article