Laboratory Software

The invisible Half of a Clinical Laboratory

How a first-in-province NGS launch, a clinical accreditation, and a pile of spreadsheets led me to build SHELF.

2026-06-16 9 min read0 viewsLaboratory Software

In September 2017, our translational laboratory in Calgary, Alberta earned its accreditation from the College of Physicians and Surgeons of Alberta (CPSA). I remember the relief more than the celebration. For most of that year I had been building something else in parallel: Alberta's first next-generation sequencing panel for myeloid cancers. Until then, a patient in Calgary newly diagnosed with AML or MDS, whose oncologist wanted a molecular profile, had to wait while a small number of samples were shipped to British Columbia or Ontario. I validated the assay, we brought it online first for Calgary and then for the whole province, and before long every new AML diagnosis in Alberta was being profiled in-house.

That is the part of the story people ask me about. It has the exciting acronyms. This piece is about the other part, the half of the lab nobody photographs.

The half nobody photographs

Accreditation was my first real exposure to the machinery underneath a clinical laboratory. Not the sequencers and the pipelines, but the standards: document control, proficiency testing, training and competency, corrective actions, and the evidence you have to produce on demand to convince an assessor that the result you released can actually be trusted. A clinical result is only as good as the system that produced it, and that system is vast. Every SOP has a version, an author, an approver, an effective date, and a review cycle. Every person who touches a sample has a competency that was assessed, signed off, and has to be reassessed on a schedule. Every proficiency-testing challenge has to be run, scored, and documented. Every deviation has to be investigated and closed. None of it is optional, and all of it is auditable.

We had almost none of this in software. We had Excel.

Our SOPs lived in folders on a shared drive, with version numbers hand-typed into filenames and a spreadsheet somewhere that was supposed to be the master index. Competency records were another workbook. Training sign-offs were initials on printed sheets that someone scanned. Proficiency testing was tracked in yet another file, and the "system" for knowing what was due was a person who remembered. It worked, in the sense that we passed. But it worked the way a rope bridge works. Every audit season, a few of us would spend weeks reconstructing a paper trail that should have been a byproduct of doing the work, not a project in itself.

What struck me was how normal this was. I have since seen the inside of many laboratories, in Canada and abroad, running world-class assays on instruments worth more than a house, and managing the quality system that legally underwrites those assays in spreadsheets and shared drives. The science gets the papers, the press releases, and the budget. The quality system gets a binder.

Iceberg diagram: above the waterline, the visible analytical work of the lab; below it, the far larger quality system that makes a result releasable

Figure 1. Every clinical result rests on a quality system far larger than the assay that produced it. The analytical work is visible. The half that makes a result releasable usually is not.

The gap nobody talks about

This is the gap I want to name, because I think it is real and almost nobody talks about it.

We have spent two decades pouring investment into the analytical half of the laboratory: better chemistry, faster sequencers, smarter pipelines, richer reports. That investment has been spectacular and worth every dollar. But the other half, the quality management system that makes a result releasable, has been left almost entirely to general-purpose office tools. When people talk about laboratory software, they usually mean the LIMS, the instrument middleware, the analysis pipeline. In our case, even that did not exist yet. We had no laboratory information system at all, so I built one first, SLIMS, which is a story for another time; it is the system that carried us through the province's pandemic testing. But a LIMS runs the analytical workflow. It was never meant to run the quality system, and ours still lived in spreadsheets. The quality layer sits outside the LIMS, the middleware, and the pipeline, invisible until the moment it fails.

And spreadsheets fail in specific, predictable ways. They do not enforce a version, so two people edit two copies. They do not sign anything, so an approval is an email you hope you can find later. They do not know that a competency expired last Tuesday, or that an SOP referenced in a procedure was retired two revisions ago, or that a proficiency-testing result was never entered. They have no audit trail, so when an assessor asks who approved this document and when, the honest answer is a shrug and a search. The information exists; it is simply scattered across files, inboxes, and memory. The failure mode is not usually a dramatic error. It is a slow accumulation of small gaps that becomes visible only under scrutiny, which in a clinical laboratory is exactly the wrong time to find it.

The frustrating thing is that this is not, at its core, a paperwork problem. It is a software problem that was never treated as one. Document control, competency, accreditation evidence, corrective actions: these are structured, relational, event-driven workflows. They are the kind of thing software is genuinely good at. The reason labs run them on spreadsheets is not that a better model is impossible. It is that the tools built for this were either enormous enterprise quality suites designed for manufacturing and priced for it, or generic document stores that treated a competency assessment and a memo as the same kind of file. Nothing was built from the point of view of the person actually running a molecular laboratory.

So I decided to build it.

From a spreadsheet I was tired of

SHELF started, honestly, as a spreadsheet I was tired of. The first version was narrow: replace the shared drive and the master index with a real document-control system, and give the lab a single place to collaborate on and track the work around those documents. It was not elegant, but it was the first time our SOPs had a genuine source of truth, with versions the software understood rather than versions we typed into filenames. That alone changed how audit season felt.

The second version is where the idea became a system. I rebuilt SHELF around the parts of quality that spreadsheets handle worst. Training and competency became a full module: assessment templates, staged sign-offs, direct observation captured at the bench on a phone instead of on paper, and reassessments the system tracks and reminds you about instead of relying on someone's memory. Accreditation became its own workspace, where audits, requirements, and checklists live together and evidence is linked to the requirement it satisfies, so that preparing for an assessment is a matter of review rather than reconstruction. I added a forms and quizzes builder, because so much of quality is really structured records: a checklist, a maintenance log, a training quiz, a validation form. If you can build those as structured data instead of loose documents, they stop being dead paper and start being something you can search, assign, and report on. Underneath it all are the unglamorous connective pieces that make a system feel like a system rather than a collection of apps: tasks and assignments, notifications so people know what they owe, and a personal view that shows each person the documents to read, the competencies coming due, and the work waiting on them.

Meanwhile, my work in genomics kept growing. In 2019, leaders from our laboratory founded a precision-diagnostics venture of their own, and in 2024 we extended it into the UAE through a partnership there. SLIMS and SHELF are both deployed in that CAP-accredited laboratory today, and they carried it through its CAP accreditation and its Department of Health assessment in the UAE. That was the moment the software stopped being an internal convenience and became infrastructure that a regulated, international laboratory depends on every day.

This is the iteration that is now in production, running quality for a CAP-accredited lab. What began as an everyday quality system for a single laboratory has grown into an enterprise-grade platform that can run quality across many laboratories at once, a whole group of them, each properly scoped within it. It keeps evolving, deliberately, across the full arc of a laboratory's quality lifecycle, from the controlled document to the competency to the corrective action to the audit. And I am convinced that the tools we use to manage quality should advance as quickly as the science they safeguard. So we are building SHELF to embrace the power and sophistication of AI, so that the system does not just store the evidence but helps make sense of it. Quality management is not a finished problem, and I would be wary of anyone who claimed it was.

Diagram of SHELF as a platform: module chips for document control, training and competency, accreditation, forms, and tasks, supporting a network of laboratories, scaling from a single lab to an enterprise

Figure 2. SHELF: an everyday quality system that has grown into an enterprise platform, running quality across a network of laboratories from a single shared foundation.

What building it taught me

Building SHELF has taught me something I did not expect about the relationship between a problem and a product. Every module in it began as a specific afternoon of frustration, a spreadsheet that would not do what I needed while a real audit was approaching. The design did not come from a whiteboard or a market analysis. It came from having stood on both sides of the bench, as the scientist releasing the result and as the director accountable for the system behind it.

But I did not build it alone. What I brought was the problem and the vision, a clear picture of what the invisible half of a laboratory actually needs. For the engineering, I leaned on Solasta Software, a local startup whose brilliant engineers had, in many cases, never set foot in a clinical laboratory, and they translated that vision into software with a craft I could not have supplied myself. The result is better for that collaboration than either side would have managed alone: a lab problem understood from the inside, engineered by people who understood software from the inside. You cannot design the invisible half of the lab from the outside, because from the outside it is, by definition, invisible. So we built it from the inside, together.

That is also why I finally wrote this down. The analytical half of laboratory medicine has no shortage of advocates. The quality half has almost none, even though it is the half that keeps patients safe and keeps laboratories open. It is not glamorous, it does not photograph well, and it is a genuinely hard and interesting problem that deserves better tools than the ones most of us have quietly accepted. If you run or work in a laboratory and any of this sounds like your Monday morning, I would like to hear from you. The best ideas in SHELF so far have not come from me; they have come from other people who live this problem and were relieved to find that someone thought it was worth solving.

My hope for SHELF is, in a way, that you never have to think about it. That it takes care of the invisible half of the lab so completely that it can stay where it belongs, in the shadows, quietly holding everything up. Because the point was never to make the quality system visible. The point was to build it well enough that it disappears, and lets the science step into the light and shine.