Laboratory information system development
A laboratory information system tracks a specimen from order to verified report: accession, processing, result entry, verification by a qualified person, release, and amendment when a released result turns out to be wrong. Most software sold as an LIS handles the first four steps and treats the last two as edge cases. Those last two are what make it a laboratory system rather than a spreadsheet with logins.
The chain of custody, step by step
An order is placed against a patient and a set of tests. A sample is collected and accessioned — given its own identifier, distinct from the order, because one order can produce several specimens and one specimen can serve several tests.
Results are entered or captured from an analyser. Then, critically, a qualified person verifies them before release. Until verification, a result does not exist as far as the clinician is concerned. Systems that let raw results flow straight to a report have removed the safety step that the whole discipline is built around.
Both accession numbers and order numbers are sequences that must not collide. We built these on dedicated counters with atomic increments and tested them by firing concurrent requests until we were satisfied, because the naive implementation duplicates silently under exactly the load a busy morning produces.
Reference ranges are not one number per test
This is where generic software gives itself away. A haemoglobin range is not a single pair of numbers — it varies by sex, and by age in bands that matter enormously for paediatrics and geriatrics.
A system storing one low and one high value per test will flag healthy children as abnormal and miss genuine abnormality in adults. Doing it properly means ranges defined per parameter with age bands and sex, and a precedence rule when several could apply — band, then sex, then generic — with the patient's age computed from date of birth at the time of the test rather than approximated.
When we built this, the age bands were stored per parameter and recomputed server-side from the date of birth, so a report printed a year later still reflects the range that applied on the day.
Critical values need an acknowledgement log
When a result crosses a life-threatening threshold, notifying someone is a clinical obligation, and "we called them" is not a record.
A serious system raises the critical result automatically, records who was contacted, by whom, at what time and what was communicated, and treats that acknowledgement as immutable once made. The communication trail then belongs on the printed report, because the report is the document that survives.
We built this as an automatic log triggered on results outside critical thresholds, with de-duplication so a repeated abnormal result does not generate a queue of identical alerts, and a visible badge so the pending ones cannot be quietly ignored.
Amendments, and why they are the real test
Released results are sometimes wrong. Ask any LIS vendor how amendment works, and you will learn quickly whether they have built one.
The correct behaviour: the original result is retained, a new version is recorded with its reason and author, the report is visibly marked as amended, and verification is forced again before the corrected version is released. What must not happen is a quiet edit that leaves no trace — which is both a clinical hazard and precisely what an inspector looks for.
Related, and equally overlooked: a mechanism to return a sample to the laboratory, and tracking for tests sent out to a reference laboratory, with the outsourcing disclosed on the report.
- Versioned results with an AMENDED marker on the report
- Forced re-verification after amendment
- Return-to-laboratory flow for samples needing rework
- Send-out tracking, with outsourcing disclosed to the patient
- Turnaround-time analytics at order and test level
Frequently asked
What is a laboratory information system?
Software that tracks a specimen from order through accession, processing, result entry, verification by a qualified person, release and — when necessary — amendment. The verification and amendment steps are what distinguish an LIS from a results table, and they are the steps generic software most often omits.
How should reference ranges be stored?
Per parameter, with age bands and sex, plus a precedence rule when several could apply — band, then sex, then generic — and the patient's age computed from date of birth at the time of testing. Storing a single low and high value per test flags healthy children as abnormal and misses genuine abnormality in adults.
What happens when a lab result is critical?
The system should raise it automatically, record who was notified, by whom, when and what was communicated, and treat that acknowledgement as immutable once made. The communication trail belongs on the printed report. De-duplication matters so a repeatedly abnormal result does not create a queue of identical alerts.
How are released results corrected?
By amendment, never by editing. The original is retained, a new version is recorded with a reason and author, the report is visibly marked amended, and verification is forced again before release. A quiet edit removes the audit trail and is exactly what an inspector looks for.
Can an LIS integrate with analysers?
Yes, and it should — manual transcription of analyser output is a well-known source of error. Integration usually happens over HL7 or a vendor-specific interface, and the results should still pass through the same verification step before release rather than bypassing it because a machine produced them.
Related
Want this built?
Tell us what you are trying to ship and we will tell you honestly whether we are the right team for it.