Your vendor sent a blank use case template with no instructions. Here's what goes in each of the 15 sections, the mistakes that surface at go-live, and a free template to get started.
Templates don't come with instructions. Somewhere early in a LIMS project, a vendor or consultant hands your lab a blank use case template, 15 headings and a lot of white space, and asks you to fill it in by next week.
Most labs know their workflow cold. What they don't know is what each heading is asking for, how much detail is enough, or what the LIMS team will do with the answer. So sections get skipped, steps lose their owners, and the exceptions that cause real trouble at go-live never get written down.
This post walks through every section of a standard use case, with a one-line rule for each. For a few of the sections that matter most, you'll also see how a real, completed use case handles them: an animal urine culture, from sample arrival through billing. At the end, the most common mistakes I see, and how to see the full example.
Section by Section
Every section gets a rule and a line on what to watch for. Four of them (Trigger, Primary Workflow, Post-Conditions, and Business Rules) also show what the completed urine culture use case says.
1. Purpose
Rule: one sentence on what the LIMS must do for this workflow.
If it takes a paragraph, you're describing two use cases. Write what the system does, not what the lab does.
In the full example: one sentence, and it names the system, not the lab.
2. Scope
Rule: draw the fence. Say where the workflow starts, where it ends, and what's outside it.
Scope is where you stop arguments before they start. If susceptibility testing is its own use case, say so here.
In the full example: the fence, and which follow-on work gets its own use case.
3. Actors
Rule: list every role, person or system, that touches the sample or the data.
Use roles, not names. Instruments and outside parties count. If an actor never shows up in the workflow, cut it; if a workflow step has no actor, add one.
In the full example: eight actors, including one that isn't a person.
4. Trigger
Rule: the single event that starts the clock.
One event, observable, in the real world. "Sample arrives" is a trigger; "lab begins testing" is not.
Example: "A urine sample arrives and is recorded in LIMS."
5. Pre-Conditions
Rule: what must already be true before the trigger fires.
These become your configuration and readiness checklist: master data, calibrated instruments, tests and limits set up.
In the full example: the readiness items that turn into a go-live checklist.
6. Workflow Overview
Rule: the stages on one line, so anyone gets the shape in ten seconds.
Five to seven stages is plenty. Detail comes next.
In the full example: five stages, sample arrival to billing.
7. Primary Workflow
Rule: every step has an owner, a verb, and what gets recorded in LIMS.
This is the heart of the document. Write the happy path, step by step, in the order it actually happens. Where a step spins off other work, note it and link the other use case.
Example: "Analyzing Technician reads plates at 24 hours and records organism and counts." If the count is TNTC, the urine is diluted, re-plated, and analysis restarts at the 24-hour mark. MALDI-TOF ID and susceptibility are flagged as their own use cases.
8. Post-Conditions
Rule: what's true when the workflow is done. If you can't check it, rewrite it.
Post-conditions are the test script in disguise. Each one should be something a validator can confirm in the system.
Example: Final results are approved by the Lab Supervisor. The report has been delivered and delivery is logged. Billing has been triggered for tests actually performed. The audit trail captures every action, user, instrument, and timestamp.
9. Business Rules
Rule: the "always" and "never" statements the system must enforce.
If a rule lives only in someone's head or an SOP, the LIMS won't enforce it. Write it here.
Example: "Billing is based on actual tests performed, not ordered." Pathogens and specific gravity require supervisor review. All results must be traceable to technician and instrument.
10. Data Objects
Rule: the nouns in your workflow, with the fields you'll need.
Go back through the workflow and circle every noun. Each one is a record the LIMS has to hold.
In the full example: nine data objects, each with the fields the LIMS has to hold.
11. Role and Permission Requirements
Rule: who can do what, and who can override.
Map each actor to the actions they're allowed. Pay special attention to who can change an approved result.
In the full example: who can accession, who can analyze, and who can override.
12. Notifications and Alerts
Rule: what the system should shout about, and when.
Think about what goes wrong when nobody's watching: missed reads, late reports, out-of-spec results.
13. Exception / Alternate Flows
Rule: every way the happy path breaks, and what happens next.
This is the section labs skimp on and go-lives pay for. For each exception, name the trigger, the owner, and where the flow rejoins (or ends).
14. Non-Functional Requirements
Rule: how the system must behave, not what it does.
Audit trail, performance, security, uptime, data retention. In regulated labs, this is where Part 11 and ISO 17025 expectations land.
15. Success Criteria
Rule: how you'll know the LIMS got it right, in terms the lab cares about.
Tie these to outcomes the lab director would sign off on, not system features.
In the full example: four outcomes a lab director would sign off on.
Common Mistakes
The same gaps show up in almost every first draft I review.
- Steps without owners. "Plates are incubated" by whom? Every step needs a role, or nobody configures the permission and nobody gets the alert.
- Thin exception flows. One line on sample rejection isn't enough. Rejected samples, re-tests, instrument downtime, client cancellations, and mislabeled tubes all need a path.
- No alerts. If the use case doesn't say what's overdue, the LIMS won't tell anyone. Missed reads and late reports become something you find out from the client.
- Billing and ERP left out. The workflow ends at the report, but the business doesn't. Say what triggers billing and what data goes to finance.
- Audit trail as an afterthought. "The system has an audit trail" isn't a requirement. Say what must be captured: user, action, old and new value, timestamp, instrument.
A useful last check: read your primary workflow aloud and ask "what if that doesn't happen?" after every step. Each answer is either an exception flow or an alert.
Get the Template, See the Full Example
Download the blank Cogsult use case template. All 15 sections, with the one-line rules as prompts.
Free use case template
A Word document, ready to fill in for any lab workflow.
Want to see a fully completed one? I'll walk you through the complete urine culture use case on a free 30-minute call: every section filled in, and how each one carries through to configuration, testing, and validation. Bring a workflow of your own and we'll talk about what yours would take. Book a 30-minute call.