LIMS requirements grounded in how your laboratory works.
I turn sample workflows into requirements your software team can build and your laboratory can test. That includes registration, sample identity, worklists, instrument interfaces, exceptions and result approval.
I work alongside your laboratory, developers and LIMS supplier, from mapping the process to reviewing what is delivered. I have worked inside three commercial systems as a user and specified one laboratory’s LIMS from the requisition to the report.
- Requirements · sample states · acceptance tests
- Analytix · FlexLab · STARLIMS, as a user
- 1 laboratory’s LIMS specified, requisition to report
- Remote first · Sweden, Europe and the Asia-Pacific
3 parties
Who does what
Laboratory staff describe what they need in the language of the bench. Developers need entities, states and rules. Requirements have to cover the exceptions staff handle every day: the split batch, the missing tube, the re-run that needs a new approval. My part is the translation and the test; the building is yours and your supplier’s.
- What I take on
Mapping the workflow as it runs, writing the requirements with acceptance criteria, the sample-state model, the rules registration must enforce, the interface requirements, the exception handling, and the acceptance tests the bench runs on what is delivered.
- Your software team or supplier
Architecture, implementation, configuration, deployment and support. I do not write production code and I do not sell a LIMS.
- Your laboratory
The people who run the process, in the workshops and at the acceptance tests, so that the system that arrives is the one they will work in.
Requisition → retention
The chain the system has to carry
Underneath its features, a laboratory information system has one job: carry a sample’s identity from the moment somebody orders a test to the day the retained sample is destroyed, without a person retyping it at any step. Each step is both a physical event and a record, and the requirements have to cover both.
- Ordering and requisition
What is asked for, by whom, on whose authority, and what has to travel with the sample.
- Reception and registration
What is accepted, queried or refused at the door; the laboratory number, the position, and the checks the system performs rather than the person.
- Sample identity
One barcode, or a pair under one barcode where the sample is an A tube and a B tube; what the system must refuse to book in; how a rack, a plate and a well inherit the identity.
- Preparation and worklists
The worklist the bench or the liquid handler works from, built from the registration data rather than typed again, and what happens when a sample fails or a batch is split.
- Analytical systems
What goes to the instrument data system, what comes back, under which identity, in what state.
- Review and release
Technical evaluation, technical approval and medical approval as separate, named acts, so the record can say who decided and when.
- Reporting
Back to whoever asked, by the route agreed, answering the question the requisition was allowed to ask.
- Retention and disposal
What is kept, where, for how long, under which ledger; and disposal as a controlled step.
Illustrative
What a requirement looks like
Each requirement is written in the laboratory’s terms, traced to the step in the flow that needs it, and paired with the test that proves it. Three rows in that shape:
| Ref | Requirement | Acceptance test |
|---|---|---|
| R-07 | A sample pair registered under one barcode is booked in only when both tubes have been scanned. A mismatch is refused with a message naming the tube that was expected. | Scan tube A alone, then A with the wrong B: both refused with the expected message. Scan the correct pair: one laboratory number, two tubes, booked in. |
| R-12 | A worklist is built from registered samples by method and batch size, in the order the analyst chooses, and cannot include a sample in the state on hold. | Put one sample on hold; build the worklist for its method. The sample is absent and listed as excluded with the reason. |
| R-19 | Technical approval and medical approval are separate, named actions by different users, each time-stamped. | Approve a result technically as user A. Medical approval by user A is refused; by user B it is accepted, and both names and times appear in the audit trail. |
Illustrative example with synthetic content. It shows the shape of the deliverable, not any client’s system or data.
8 deliverables
What you get
Before the build
- Workflow maps
Current state, with every handoff and workaround, and future state, the operation the system has to carry, agreed with the people who will run it.
- Requirements
What the system must do, in the laboratory’s terms, traceable to the step in the flow that needs it, and the same requirements as user stories with acceptance criteria.
- Sample-state model
The states a sample may be in, what moves it between them, and who is allowed to.
What the system must carry
- Registration and barcodes
What a label carries, what registration checks and refuses, how pairs, racks and plates inherit identity.
- Worklist logic and interfaces
How a worklist is built, filtered, split and closed; what passes between the LIMS and each instrument data system, in which direction, under which identity, and what is rejected.
- Exception handling
The failed sample, the split batch, the re-run, the challenged result: specified, not discovered.
- Traceability
Who did what, when, to which sample, against which lot, designed in now for the questions asked years later.
At acceptance
- Acceptance and UAT
Tests written from the workflow map, run by the bench, with pass criteria agreed before the first script; and the workshops that produce all of the above, with the laboratory and the developers in one room.
4 systems, 1 identity
Relevant experience
At ABC Labs in Stockholm, a covid testing operation becoming an accredited drugs-of-abuse laboratory, the first document I wrote was the flow: the whole operation end to end, in nine steps, across five sample streams. The same document carried a second diagram, which system hands the sample to which: a customer ordering portal, a sample registration system, the LIMS and the instrument data systems, four pieces of software that between them had to carry one identity from the requisition to the report without anybody retyping it. My job was the translation between the two charts, and then testing what the developers delivered against the way the work ran.
Some of what they built started as a stopgap. Where the LIMS did not yet have a feature, the laboratory ran on validated, versioned, change-logged spreadsheets with every field checked at entry. When the developers reached each feature they had the sheet: every rule in daily use and already agreed by the people who would live with it. The stopgap turned out to be the specification.
The rules that came out of the flow are the kind a system either enforces or does not. In workplace drug testing the sample arrives as an A tube and a B tube under one barcode, so registration prompts for the second scan and refuses a pair that does not match. I wrote that chain-of-custody procedure against the European Workplace Drug Testing Society’s guidelines, and the version in use is the second one, rewritten after a non-conformity.
Before that, eleven years in clinical pharmacology at Karolinska University Hospital, where I integrated the department’s worklists with its automation platforms: the deck matched each tube’s barcode to the worklist, reported a tube that was on the list but not on the carrier, and pipetted in the worklist’s order whatever order the tubes were loaded in. I have worked inside Analytix, FlexLab and STARLIMS as a user, which is a different education from selling one. The flow document and the systems chart and the ledgers that became the specification are on the selected work page.
4 steps
How the work runs
- ReviewA walk-through of the flow as it runs, on site or remotely, and a written proposal: the systems it touches and where the process and the system disagree. A couple of days.
- Map and specifyCurrent state and future state with the bench, then the requirements, states, rules, interfaces and exceptions, in the laboratory’s shape and the developers’.
- Through the buildQuestions answered, decisions recorded, scope held, alongside your software team or supplier.
- Test and hand overAcceptance tests against the workflow map, run by the people who will use the system. The specification and the test record stay with you, in your document control.
Most of this runs remotely, workshops included; site time is for watching the bench, and a longer on-site engagement is open for the right project. Engagements run from a couple of days to several months and are quoted in writing before they start; the commercial answers cover the rest.
Scope
Scope, and one disclosed referral
I am not a software engineer and I do not sell a LIMS. I am not a certified implementation partner for any LIMS vendor, and the work runs alongside your software team, your vendor or your integration partner rather than in place of them. Where the system is one part of launching a whole service, that is laboratory commissioning; where the worklist ends at a liquid handler, the deck side is laboratory automation.
One commercial relationship, stated here because the rest of this page rests on independence from vendors. For established laboratories interested in an AI analysis workflow on their own results, I can make an introduction to Expert Intelligence, and I earn a commission if the laboratory takes it up through me. That introduction is separate from the requirements work on this page. I will not raise it unless you ask, and if you do, I will say first whether I think it fits.
Six services
First step
Discuss your LIMS project
Tell me which process or system does not match the laboratory: what the bench does, what the system expects, and where the workarounds are. If you are the software team, tell me what the laboratory keeps asking for that you cannot pin down. I will reply with the questions I need and tell you what I would map first. The first conversation is free. The terms, travel and the other commercial answers are on the contact page. If you would rather not use a form, write to [email protected].
Contracting
- Consulting delivered through Ebihara Solutions (Sweden), a sole trader approved for F-skatt; organization and VAT numbers on every invoice.
- Your NDA signed and your document control followed; no professional indemnity insurance; laboratories in Sweden, Europe and the Asia-Pacific.