Scientific, research, and laboratory software

Laboratory Information Management System Requirements Checklist

A practical engineering checklist for laboratories replacing paper logs, sample spreadsheets, disconnected instruments, and fragile result workflows with a traceable operating system.

Published by Kennedy Gichobi · Fact-checked by OpenAI Codex research review · Published 2026-08-19 · 1956 words

Start with the laboratory decision and evidence chain

A laboratory information management system should make scientific and operational evidence more dependable. Begin with the decisions the laboratory cannot make reliably today: whether a sample is suitable, which method and version applies, what work is pending, whether an instrument was qualified, who reviewed a result, what changed, which report is authoritative, and whether every required artifact can be reconstructed. “Digitize the lab” is too broad to guide architecture or acceptance testing.

Map representative journeys from request and study setup through kit or container preparation, collection, receipt, accessioning, aliquoting, storage, work assignment, preparation, analysis, calculation, technical review, approval, reporting, amendment, retention, disposal, and retrieval. Include insufficient quantity, damaged container, incorrect label, temperature excursion, contamination concern, late instrument file, repeated run, changed method, failed control, corrected result, missing reviewer, and client cancellation. Define a focused first release around one complete evidence chain.

Establish the regulatory and quality boundary explicitly

Laboratories differ across research, clinical, environmental, food, manufacturing, forensic, calibration, and product-development contexts. Applicable quality systems, accreditation, privacy rules, record controls, method requirements, and reporting obligations depend on work, geography, sponsor, customer, claims, and intended use. Qualified quality, scientific, security, privacy, and legal owners must define that boundary. A configurable audit trail does not make a product compliant by itself.

Create a traceability matrix from each approved requirement to configuration, code, procedure, risk control, test evidence, owner, and release. The FDA's guidance on Part 11 scope and application explains its interpretation for certain electronic records and signatures, including a risk-based approach; organizations must determine applicability to their records and predicate rules. Keep regulated and nonregulated workflows distinguishable rather than applying an unexplained “validated” label to the entire platform.

Build stable identities for samples and derived material

Separate request, subject or source where applicable, collection, sample, container, aliquot, pool, extract, plate, batch, test, result, report, and disposal event. Give each a durable internal identifier and model parent-child relationships explicitly. Human-readable labels and barcodes are representations, not the identity itself. Preserve retired and reprinted labels, and detect accidental reuse.

Record type, matrix, quantity, unit, condition, hazard, preservative, collection and receipt time, timezone, collector, custody, storage requirement, priority, project, and restrictions as structured facts where they affect work. Do not overwrite the original observation when a reviewer corrects it. Record the correction, reason, actor, time, and effect. Test split and pooled samples, multiple containers with the same external identifier, anonymous research codes, relabeling, partial consumption, return to storage, and disposal reversal.

Make chain of custody and location event-based

Current location is a useful projection, but the defensible record is a sequence of custody and location events. Each transfer should capture source, destination, person or system, time, container, condition, evidence, and exception. Support freezer, shelf, rack, box, plate, well, temporary bench, courier, external laboratory, archive, and disposal locations without encoding the entire hierarchy into one fragile text value.

Define scanning behavior for offline work, unreadable labels, duplicate scans, bulk movement, partial acceptance, and transactions submitted out of sequence. A user should not be able to make material disappear by editing a location field. Temperature or environmental monitoring should retain device identity, calibration context, timestamps, gaps, thresholds, acknowledgement, and disposition. An alarm proves a threshold rule fired; it does not by itself establish sample impact.

Version methods, specifications, and calculations

Represent method, procedure, specification, limit, unit, instrument class, preparation, calculation, reference range, quality-control rule, and reporting rule with effective versions. A work item should resolve the approved version for its context and preserve it after later revisions. Avoid a single mutable template that makes historical results appear to have been produced under today's instructions.

Calculations need named inputs, units, precision, rounding, constants, formula version, intermediate values where necessary, and test cases. Separate raw observation, imported instrument value, normalized value, calculated result, qualifier, interpretation, and report display. Do not turn strings such as “less than,” “not detected,” and “unable to determine” into zero. Test unit conversion, locale decimal separators, values near limits, significant figures, missing inputs, corrected dilution, and recalculation after a method change.

Integrate instruments without erasing provenance

For every instrument, define device identity, software and firmware where relevant, connection method, file or message format, run identifier, sample mapping, timestamps, units, quality flags, raw-data location, retry behavior, duplicate detection, correction, and outage process. Preserve the source artifact and a cryptographic integrity value when appropriate. Parsing a file into rows should not destroy evidence of what the instrument actually produced.

Separate acquisition from acceptance. A result imported successfully may still require control evaluation, sample reconciliation, analyst review, or repeat. Never assign results to samples using position alone if a stable run and sample mapping is available. Test partial files, delayed exports, repeated upload, unexpected columns, changed firmware, corrupted values, clock drift, instrument replacement, mismatched plate orientation, and a result arriving after the work was canceled.

Design work assignment around capability and readiness

Work availability may depend on sample condition, method, instrument status, analyst qualification, reagent or standard, preparation completion, control material, priority, due date, hazard, and batching rules. Make these dependencies visible. A queue should explain why work is ready, blocked, or overdue rather than rely on tribal knowledge and colored cells.

Separate requested, received, accepted, scheduled, prepared, in progress, awaiting data, awaiting review, rejected, canceled, completed, and amended states. Every transition needs authority, reason, time, and linked evidence. Support reassignment and shift handover without changing who performed earlier work. Operational metrics should distinguish laboratory processing time from customer hold, external testing, missing information, and review delay.

Treat quality control and deviations as decision workflows

Define control type, lot, target, range or rule, run context, observation, evaluation version, outcome, reviewer, and resulting action. Automated rules can surface an exception, but approved scientific owners must define their meaning. Avoid allowing a user to remove a failed control and rerun the calculation until the batch passes. Preserve excluded data, reason, authorization, and effect.

Link nonconformance, deviation, investigation, corrective action, preventive action, maintenance, retraining, and change control without forcing them into one generic note. Each has different ownership and closure evidence. Test an invalid run that already supplied a report, a control lot corrected retrospectively, a deviation spanning multiple batches, and an instrument found out of tolerance after prior work. The system should identify potentially affected records without declaring scientific impact automatically.

Separate review, approval, signature, and release

Technical review may examine calculations, flags, controls, sample identity, method, instrument evidence, and analyst comments. Approval may authorize the result or report for a defined use. An electronic signature may carry additional meaning under applicable rules. Model these as explicit actions with role, meaning, record version, time, and authentication context. A typed name inside a note is not equivalent to a controlled signature.

Prevent a reviewer from approving an obsolete version after a correction. Material changes should invalidate downstream review according to approved rules and show exactly what changed. Define delegation, absence, conflict of interest, dual review, emergency release, and revocation. The release screen should show unresolved exceptions and evidence; it should not make users search across tabs before taking an accountable action.

Produce reports from immutable release records

A released report needs a stable identifier, version, recipient, result set, method and specification context where required, units, qualifiers, approvals, issue time, and distribution record. Generate the document from an immutable release snapshot so later master-data edits do not alter what was issued. Amendments should link to the prior version, state what changed and why, and trigger controlled redistribution.

Define machine-readable delivery as carefully as PDF delivery. For APIs, portals, or messages, specify schema version, identifiers, units, statuses, corrections, acknowledgements, retries, and reconciliation. Expiring client access should not make the laboratory unable to demonstrate what it delivered. Watermarks, access logs, and download restrictions can support control, but they do not replace correct authorization and recipient verification.

Protect intellectual property and sensitive data by purpose

Laboratory systems may hold participant information, formulas, product specifications, environmental locations, customer identities, unpublished findings, controlled methods, trade secrets, and security-sensitive facility information. Classify data and grant access by organization, project, study, laboratory, method, role, purpose, and record sensitivity. A project membership should not automatically expose every instrument file or quality investigation.

Use least privilege, strong authentication, service identities, protected secrets, environment separation, encrypted transport, audit logs, dependency governance, secure exports, backups, and incident response. NIST Cybersecurity Framework 2.0 provides a useful governance structure. Test former staff, reassigned researchers, external collaborators, support personnel, shared workstations, malicious files, guessed identifiers, forwarded report links, bulk export, compromised instrument computers, and emergency credential revocation.

Make audit trails useful and reviewable

Capture creation, modification, deletion or retirement, review, signature, release, access where policy requires, configuration change, permission change, integration event, and export with actor, time, record, before and after meaning, reason, and source. Protect audit records from ordinary editing. Synchronize time and display timezone clearly. System-generated events need a service identity and correlation identifier rather than appearing as an anonymous administrator.

Audit review should be risk-based and usable. Provide filters for material changes, unusual access, repeated failed actions, backdated entries, privilege changes, disabled controls, bulk export, and integration overrides. Retaining millions of events is not the same as controlling the process if no one can retrieve and interpret the relevant chain. Define review frequency, reviewer independence, evidence, escalation, and retention.

Design for benches, gloves, scanners, and accessibility

Laboratory users may work with gloves, scanners, shared terminals, limited bench space, low connectivity, protective equipment, and strict contamination boundaries. Minimize typing, support reliable barcode workflows, make device focus visible, prevent scan input from reaching the wrong field, and confirm high-consequence actions. Offline operation needs a bounded use case, visible synchronization state, conflict handling, and a procedure for authoritative timestamps.

WCAG 2.2 supplies a testable accessibility baseline for web interfaces. Test keyboard operation, focus, labels, errors, status messages, contrast, zoom, target size, and assistive technologies. Do not make a plate map, chart color, drag action, or scanner the only way to complete a task. Accessible design also helps tired users working under time pressure and reduces transcription mistakes.

Validate migration, resilience, and client ownership

Profile sample registers, spreadsheets, instrument files, result databases, methods, specifications, user records, audit history, reports, storage maps, and external identifiers before migration. Define which source is authoritative and reconcile counts, relationships, status, units, and representative records. A successful import log is not evidence that scientific meaning survived. Preserve original extracts and signed reconciliation evidence according to the approved plan.

Set recovery and data-loss objectives by workflow. Receipt and custody, active instrument ingestion, result review, reporting, and historical search have different consequences. Rehearse identity outage, network partition, instrument backlog, corrupted import, unauthorized configuration change, expired certificate, failed backup, and restoration. Require ownership or transferability for repositories, cloud accounts, domains, integrations, encryption keys, data exports, documentation, validation evidence, and deployment access.

Evaluate the solution with one difficult sample

Ask a vendor or developer to trace a sample received with an external duplicate identifier and temperature exception, split into aliquots, moved offline, prepared under a method later revised, analyzed on an instrument whose clock is wrong, imported twice, associated with a failed control, repeated after reagent replacement, reviewed, released through an API, corrected, and included in a restricted research dataset. A credible design explains identity, provenance, versions, authorization, scientific review, auditability, correction, distribution, and recovery.

Then compare a configurable LIMS, integration around existing scientific products, and focused custom development against real workflows and obligations. Share laboratory type, sample volume, methods, instruments, locations, quality framework, review rules, reporting, integrations, retention, security, and recurring failures through the project questionnaire. Use quick contact for a focused discussion, or review the software data migration checklist before planning a replacement.

Authoritative references

Related software planning guides

Explore custom software development