LIMS Platform
Laboratory Information Management System (LIMS)
Problem Statement
Laboratory testing in a manufacturing environment involves multiple laboratories, machines, materials, grades, processes, test parameters, and specifications. The existing workflow required users to manage and connect this information across different activities, while laboratory personnel needed to accurately capture test results and identify deviations.
The key product challenge was to build a centralized system where master configuration drives the testing process, results are evaluated automatically against the applicable specification, and out-of-specification results are immediately surfaced to the relevant users.
The objective was to create an end-to-end workflow:
Master Configuration → Test Creation → Test Execution → Result Capture → Specification Evaluation → OOS Detection → Alert → Notification → Resolution → Reporting
Key Challenges
1. Complex Master Data
The testing workflow depends on multiple interconnected masters:
Locations
Process Templates
Materials
Grades
Laboratories
Machines
Forms
Users and Roles
The challenge was to ensure that these configurations remained connected and were correctly reflected during test execution.
2. Supporting Multiple Laboratories and Machines
The system needed to support different laboratories and machines without creating separate workflows for each one.
The solution therefore needed to be configuration-driven, allowing new laboratories and machines to be added through master configuration.
3. Accurate Test Result Evaluation
A laboratory user should not have to manually determine whether a result is acceptable.
The system needed to evaluate:
Material → Grade → Specification → Test Parameter → Measured Result
and determine whether the result was within the configured specification.
4. Out-of-Specification Handling
An abnormal result should not simply be stored as another value.
When a result falls outside the configured specification, it should be clearly identified as Out of Specification (OOS) and highlighted in red so that the user can immediately recognize the deviation.
5. Escalating Critical Deviations
Identifying an OOS result is only the first step. The relevant quality users need to be informed and should have enough context to understand what went wrong.
This required an alert workflow connected directly to the test result.
User Research & User Journey
The primary user for the testing workflow is the laboratory user performing the test.
The key insight was that this user should focus on performing the test and entering the measured result, rather than navigating through multiple configuration screens.
Primary Users
| User | Primary Need |
|---|---|
| Laboratory User | Perform tests and capture results |
| Quality User | Review deviations and resolve alerts |
| Administrator | Configure masters, users and system settings |
| Reviewer / Management | Review testing and exception information |
Laboratory User Journey
1. Test Context
The user receives or opens the applicable test context.
2. Test Parameters
The system provides the parameters that need to be tested based on the configured setup.
3. Test Execution
The laboratory user performs the physical test using the applicable laboratory and machine.
4. Result Capture
The user enters the measured value for each parameter.
5. Specification Evaluation
The system compares the entered value with the applicable specification.
6. OOS Identification
If the value is outside the acceptable range, the result is marked as OOS and highlighted in red.
7. Alert
If an applicable alert rule exists, the system creates an alert and notifies the configured recipients.
8. Resolution
The quality user reviews the alert and resolves the deviation.
The key principle is:
The laboratory user should be able to perform the test without needing to understand the underlying master-data configuration.
Solution
The product was designed as a connected system where each stage feeds the next stage.
Core Workflow
Location / Laboratory / Machine
↓
Process Template
↓
Material / Grade / Specification
↓
Test Configuration
↓
Test
↓
Test Parameters
↓
Measured Results
↓
Specification Evaluation
↓
OOS
↓
Alert Management
↓
Notification
↓
Resolution
↓
Reporting
This approach ensures that the information entered during configuration is reused throughout the testing workflow rather than being manually recreated.
System Architecture
The product can be viewed through four major layers.
1. Master Data Layer
This layer defines the laboratory environment.
It contains:
Location
Process Template
Material
Grade
Laboratory
Machine
Form configuration
User and role configuration
The purpose of this layer is to establish the configuration that will be consumed by the testing workflow.
2. Test Execution Layer
This layer is used by the laboratory user.
It is responsible for:
Creating/accessing the applicable test
Displaying test parameters
Capturing measured values
Validating required information
Maintaining the test context
3. Evaluation & Alert Layer
This layer determines whether the captured result meets the applicable specification.
The logic is:
Measured Result → Compare with Specification → Within Range / OOS
If the result is OOS:
OOS → Evaluate Alert Rule → Create Alert → Notify Users
4. Reporting Layer
The testing and alert information generated by the operational workflow becomes the underlying data for reporting and historical analysis.
Alert Management
Alert Management was designed as the exception-handling layer of the product.
Instead of notifying users about every test, the system focuses on configured exceptions that require attention.
Alert Rule Configuration
An administrator can configure:
Alert Name
Alert Type
Process Type
Materials to Monitor
Alert Scope
Notification Users
Additional Email Addresses
Active / Inactive status
For the OOS use case, the alert can be configured to trigger when any element is out of specification.
Alert Flow
Test Submitted
↓
Specification Evaluation
↓
Any Parameter OOS?
↓
Yes
↓
Check Applicable Alert Rule
↓
Create Alert
↓
Send Notification
↓
Record in Alert Log
↓
Quality User Reviews Alert
↓
Resolve Alert
Alert Details & Traceability
An alert should provide enough information for the quality user to understand the deviation without having to search through the entire test manually.
The alert context includes:
Alert Rule
Alert Type
Trigger
Timestamp
Location / Plant
Material
Test ID
Parameter
Measured Value
Target
Acceptable Range
Notification Status
Resolution Status
The important design principle is that the alert is linked to the originating test, rather than being an isolated notification.
This creates a traceable chain:
Alert → Test → Material → Parameter → Measured Result → Specification
Key Product Decisions
Configuration-Driven Design
Laboratories and machines are represented as configurable entities so that the product can scale without creating separate workflows for every laboratory.
Master-Driven Testing
The testing workflow consumes configured master data instead of requiring users to manually recreate test definitions.
Automatic Specification Evaluation
The system determines whether a result is acceptable rather than relying on the laboratory user to manually interpret the specification.
Exception-First Experience
OOS results are immediately highlighted so that abnormal results receive attention without requiring users to inspect every value manually.
Traceable Alerts
Every alert maintains a relationship with the test and the specific parameter that caused the deviation.
Separation of Configuration and Execution
Administrators configure the system, while laboratory users focus on performing tests and recording results.
Success Metrics
I would measure the success of the product using operational metrics:
Test completion rate – Are laboratory users successfully completing tests?
Result completion rate – Are required test parameters being captured?
OOS detection rate – Are specification deviations being consistently identified?
Alert notification success rate – Are configured recipients receiving alerts?
Time to acknowledge OOS – How quickly does the responsible team become aware of a deviation?
Alert resolution time – How quickly are deviations resolved?
Manual rework rate – Is the system reducing repeated data entry and correction?
Laboratory and machine adoption – Is the workflow being consistently used across the configured environment?
Product Outcome
The product transforms laboratory testing from a collection of disconnected activities into a single connected operational workflow.
The core product logic is:
Configure → Test → Capture → Evaluate → Detect OOS → Alert → Resolve → Report
The key product value is not simply digitizing laboratory forms. It is creating a system where configuration drives execution, execution produces controlled results, results automatically identify exceptions, and exceptions become actionable and traceable.
06 Sep 2026
Keywords
