Diagnostic Lab Reporting System with Verifiable Reports

The problem small diagnostic labs have with results and reports

Small pathology and diagnostic labs, including collection points and hospital labs in smaller cities, often run on a mix of paper registers, spreadsheets and a Word template for reports. Reference ranges are typed by hand, so a child's haemoglobin may be judged against an adult range. Critical values, such as a dangerously low potassium, depend on a technician noticing. Patients photograph reports and share them over WhatsApp, and there is no easy way for a doctor or an employer to check that a report was not edited.

These are real safety and trust problems, and they sit in exactly the kind of organisation that cannot afford an enterprise laboratory information system.

What already exists and the gap

• SENAITE is an open source LIMS (the successor of Bika LIMS) covering the analytical workflow from sample intake to report publication, built on the Plone framework.
• OpenELIS Global is an open source laboratory information system backed by a foundation and used in public health lab networks.
• Many commercial lab systems are sold locally as installed software with per-branch licences.

The open source systems are capable but heavy to install, configure and customise for a three-person lab, and they target research or public health workflows. The gap is a lightweight, hosted system that gets the clinical safety basics right (age and sex specific ranges, critical flags, delta checks, sign-off) and adds verifiable reports, which is the thing patients and doctors actually ask for.

What you build

Roles: front desk (register patient, create order, print label), technician (enter results), pathologist (verify and sign), admin (catalogue, ranges, users), and the public verifier (anyone scanning the QR).

Flow: registration and order, sample labelled and tracked through stages, results entered with automatic flags, pathologist review with any comments, report released as a PDF with a QR code. Anyone scanning the code sees the patient initials, tests, date and a clear "genuine" or "not found" message.

The technically interesting part

There are two parts worth defending in front of evaluators.

A reference range engine. Ranges depend on test, unit, sex and age band, sometimes on pregnancy status. Model them as data with clear precedence rules, compute the patient's age at collection time, and make every flag explainable ("high: 13.2 against range 4.0 to 11.0 for female adult"). Add delta checks: if a value changed more than a configured percentage since the last result, ask the technician to confirm, a standard lab safety practice.

Tamper-evident reports. When a pathologist signs, the system produces a canonical JSON of the report content, hashes it and stores a signature. The QR encodes the report ID and a short token. The verification page recomputes and compares. Any later edit creates a new version and the old QR says "superseded". Keep the verification page free of sensitive data beyond what the lab chooses to show.

How to evaluate it

• Flag correctness: a test suite of at least 100 result cases across age bands and sexes, each with an expected flag, all passing.
• Safety: seed 20 critical values in a simulated day and measure how many were acknowledged and how fast.
• Integrity: demonstrate that editing a PDF or the database row after sign-off is detected by the verifier.
• Turnaround: in a simulated or pilot day, report median time from sample received to report released per stage.
• Usability: 5 technicians or MLT students enter a CBC panel; measure time and errors.

Suggested plan

1. Weeks 1 to 3: visit a lab, collect their report template and test list, and model ranges with a pathologist's help.
2. Weeks 4 to 8: catalogue, ranges engine with tests, patient and order entry.
3. Weeks 9 to 12: sample tracking, result entry, flags and delta checks.
4. Semester 2, weeks 1 to 4: verification workflow, signed PDF reports and verifier page.
5. Weeks 5 to 8: turnaround dashboard, audit log, access control.
6. Weeks 9 to 14: pilot or realistic simulation, evaluation, report.

Path to a product

Your first customer is a single independent lab or collection centre, found through a doctor or a medical technology department at your university. Charge a monthly subscription per branch, or a small fee per report for very small labs. The verifiable report is also a selling point for labs, because it protects their name from forged reports.

Scope warning

Do not attempt direct analyser interfacing over serial or network protocols in the core scope. Do not build billing with insurance, a hospital information system, or radiology imaging. Never use real patient data without written consent and supervisor approval; use synthetic data for development.

Learn what you need on Sefism

• Backend roadmap : data modelling, auth and audit trails for a regulated workflow.
• System design cheat sheet : versioning, hashing and verification patterns.
• OWASP ASVS : use it as a checklist for access control on health data.
• PostgreSQL Documentation : constraints and JSONB for versioned reports.
• EU Data Protection Rules for Business : a good reference for how health data should be handled even outside Europe.

Get help with this idea

Find a pathologist willing to review your reference range model early. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session