LabLynx One LIMSpec
Publisher: John Jones
This provides the documented set of features and functions against the latest release of the LIMSpec, Laboratory Software standards and specifications. This tool allows you to objectively evaluate and analyze the LabLynx One solution based upon industry standards that are important for your lab.
LIMSpec - LabLynx / LabLynx One
LIMSpec is the shared, standards-referenced vocabulary for laboratory informatics: 469 functions across 28 categories spanning LIMS, LIS, ELN, and SDMS, applied the same way in every vendor profile so a laboratory can evaluate any vendor on the facts, and a vendor can describe its own product completely and accurately.
The LIMSpec and How to Use It
A practical walkthrough of what this document is, how a laboratory evaluating software should read and use it, and how a laboratory informatics vendor positions its own product accurately and completely within it.
What Is the LIMSpec?
LIMSpec is a fixed, standards-referenced catalog of 469 individual laboratory informatics functions, organized into 28 categories, covering the full functional territory spanned by LIMS, LIS, LES, ELN, SDMS, business intelligence, AI/automation, security, and compliance capabilities. It exists so that any laboratory informatics vendor's product can be described against the exact same functional checklist, in the exact same language, rather than through each vendor's own marketing terminology.
The matrix itself is vendor-neutral: this master edition names no vendor, scores nothing, and favors no product category. A specific vendor's profile is a separate document produced by applying this same fixed matrix to that vendor's own public documentation, marking each of the 469 functions as either Documented (confirmed in the vendor's own materials) or Not Supported (not confirmed), with a brief note explaining what was found. The result is a single, consistently structured record of what a vendor's own documentation actually says, function by function.
- Laboratories evaluating software get a single, comparable, evidence-based reference for what each vendor's documentation actually claims — rather than reconciling incompatible feature lists across a dozen sales decks.
- Vendors get a structured, comprehensive framework for describing their own product completely and accurately, including a dedicated place (Chapter 29) to highlight functionality that falls outside the standard matrix entirely.
- Everyone benefits from a shared vocabulary: "chain-of-custody tracking" or "21 CFR Part 11 electronic signatures" means the same specific thing in every vendor's profile, because it is defined once, centrally, rather than redefined by each vendor's own copywriting.
How a Laboratory Uses This Document (the Buyer)
A laboratory's evaluation team typically works with completed profiles for each vendor under consideration, comparing them side by side on the facts each vendor has documented.
Reading a Completed Vendor Profile
Every function in the matrix is clickable. Each of the 28 categories lists its functions in a simple, ordered list — clicking any one opens its detail view, showing the standard Functional Requirement — a fixed, vendor-neutral explanation of what the function means and why it matters — alongside a Vendor Information tab containing that specific vendor's status and supporting detail for that function.
The Vendor LIMSpec Score shown in the top banner is a running total of points earned across all 469 functions — Off-the-Shelf and Configurable each contribute 1 point, Extensible contributes 0.5 point, and Not Supported contributes 0 — a quick, directly comparable summary figure across vendors, though it should never substitute for actually reading the specific functions that matter to a given lab's own work. A high overall score built on functions irrelevant to a particular discipline is less useful than a focused review of the categories that discipline actually depends on.
How a Vendor Uses This Document (the Seller)
A vendor producing its own profile from this matrix works through three things: its Vendor Profile, every applicable function in the 28-category matrix, and, if it has functionality the standard matrix does not cover, Chapter 29.
Filling In the Vendor Profile
Chapter 1 captures basic corporate context — legal/product name, headquarters, ownership, deployment options, licensing model, pricing, compliance and security posture, and so on — using the same Edit-button pattern shown above. Filling in the Vendor / Product field also updates the document's own title banner, so the profile is clearly identified as soon as it is opened.
Answering Functions
For each of the 469 functions, a vendor confirms whether its own documentation supports it. Opening a function and switching to the Vendor Information tab reveals an Edit button; clicking it exposes a status selector and a rich-text editor for the supporting detail — what specifically is supported, how, and (where useful) a source reference.
This is where accuracy matters most for a vendor's own credibility. A function marked Off-the-Shelf should be genuinely confirmed in the vendor's own public materials as working out of the box — not implied, not assumed by analogy to a competitor, and not aspirational. A function that only works through configuration should be marked Configurable rather than Off-the-Shelf, and a function that requires custom coding or development should be marked Extensible rather than either. Any such distinction, and any partial support, should be explained plainly in the Vendor Information text. The whole value of a LIMSpec profile to a reader depends on this discipline being followed consistently, function by function.
Adding What the Standard Matrix Doesn't Cover
Some products have genuinely distinctive functionality that falls outside all 469 standard functions — a proprietary integration, a unique automation capability, a specialty workflow built for one industry. Chapter 29, Vendor Added Categories, exists for exactly this: a vendor can define its own categories, each numbered 29.1, 29.2, and so on, and add function points to them using the same Function / Functional Requirement / Vendor Information / Status structure as the standard matrix. Every function added here counts toward the overall Vendor LIMSpec Score exactly the same way a standard function does, earning points by status (1 for Off-the-Shelf or Configurable, 0.5 for Extensible, 0 for Not Supported).
This chapter is the right place for genuine differentiation — not a place to restate standard functions in different words to make the profile look larger. A reader comparing profiles across vendors will notice the difference.
Adding a Vendor-Specific Function Within a Standard Category
Sometimes a vendor has a genuine extension of one specific standard category — not distinctive enough to warrant an entirely new Chapter 29 category, but not one of the 469 fixed functions either. Every standard category page has its own + Add Function button below its function list, right where the category's Chapter 29-style extensions belong. A function added this way uses the same Function / Functional Requirement / Vendor Information / Status structure as everything else, counts toward the overall Vendor LIMSpec Score the same way a standard function does, and can be freely edited or deleted afterward, since it is entirely vendor-authored rather than part of the fixed matrix. The 28 standard categories themselves are permanently fixed and can never be removed — only the vendor-added functions beneath them can be.
Hiding a Standard Function
The 469 standard functions cannot be deleted — deleting a function that is part of the fixed matrix would create a real risk that a future Upgrade migration reintroduces it, since the newer template always has all 469 back by default. Instead, any standard function can be hidden: open the function, switch to the Vendor Information tab, and use the "Hide this function" button next to Edit. A hidden function stays completely intact in the underlying data, and any points it earned before being hidden still count toward the LIMSpec Score — hiding only removes it from that category's visible list. Each category shows a small note when it has hidden functions ("N function(s) hidden from view — Show hidden"), with a link to reveal them again (shown dimmed and tagged "Hidden") for review or to Unhide.
Saving and Sharing a Completed Profile
Every edit — a function's status, a Vendor Profile field, a vendor-added category — is held in the browser until it is downloaded. The sidebar offers two download formats: an updated copy of this same interactive HTML document, and a Word (.docx) export covering the Vendor Profile chapter and the full Feature Matrix, generated entirely in the browser with no data leaving the machine.
Keeping Your LIMSpec Profile Current
The LIMSpec master template is periodically updated — new functions, corrected wording, new capabilities like the ones described throughout this chapter. A vendor profile built from an older version of the template does not automatically pick these up. The Upgrade My LIMSpec button, in the dark navy cover banner next to the LIMSpec Score badge, exists to bring an older, filled-out profile forward to the latest template without losing the work already done.
This button only appears on the blank Master Template — not on a filled-out vendor profile — because only the Master Template is a valid upgrade target. The distinction matters: the file currently open is always the destination; the file selected in the upgrade dialog is always the source.
To upgrade an older profile: open the current, blank Master Template, click Upgrade My LIMSpec, and select the older filled-out file. The file is validated the moment it is selected — a clear error appears immediately if it is not a valid LIMSpec file — before anything is migrated.
Clicking Upgrade migrates every function status, every Vendor Profile field, and any Chapter 29 vendor-added categories from the older file into a fresh copy of the current template, matching by function name and field label. The Master Template page itself is never changed — the result is presented as a summary, with an explicit download link for the upgraded file.
Matching works by exact function name and field label. If a function was renamed between versions, its old data will not carry over automatically — the summary reports this plainly as an unmatched item, rather than silently dropping it, so nothing is lost without you knowing about it.
This entire application — the matrix, the editing tools, the scoring, the Word export — lives inside the single HTML file being viewed right now. Nothing is uploaded anywhere; every edit stays on the device until the file itself is downloaded. A completed profile is simply this same file, saved with its data filled in.
Open Access License
This document, the Lab Informatics (LI) Feature Matrix it defines, and every vendor profile published in the LiMSwiki Laboratory Informatics Vendor Profile series are made available under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).
What This License Permits
Under CC BY-NC-SA 4.0, anyone is free to:
- Share — copy and redistribute this document, the Feature Matrix, or any vendor profile in the series, in any medium or format.
- Adapt — remix, transform, and build upon the material for any non-commercial purpose, including producing a new vendor profile using the same Feature Matrix and scoring rubric.
What This License Requires
These permissions come with three conditions that apply to any use of this material:
- Attribution. Appropriate credit must be given to LiMSwiki.org, a link to the license provided, and any changes made to the original material clearly indicated. This must be done in a reasonable manner, but not in any way that suggests LiMSwiki.org endorses the user or their use of the material.
- NonCommercial. This material may not be used for commercial purposes. Internal evaluation, academic research, and non-commercial reference use are permitted; incorporating this document or its content into a paid product, a commercial consulting deliverable, or any other revenue-generating use is not, without a separate commercial license from LiMSwiki.org.
- ShareAlike. If this material is remixed, transformed, or built upon, the resulting contributions must be distributed under this same CC BY-NC-SA 4.0 license.
This summary is not a substitute for the license itself. The complete, legally binding terms are available at creativecommons.org/licenses/by-nc-sa/4.0.
About This Document
This is LIMSpec, the master reference document for the LiMSwiki Laboratory Informatics Vendor Profile series (Version 2026R1.49). It defines the "Lab Informatics (LI) Feature Matrix" (referred to throughout this series simply as the "Feature Matrix") — a fixed, standards-referenced set of 469 functions across 28 categories representing the complete functional scope of laboratory informatics as a domain. This document contains no vendor names, scores, or evaluations. It exists so that any vendor profile in the series can be produced by applying the same fixed matrix and scoring rubric to that vendor's own documentation.
What the Feature Matrix Is
The Feature Matrix was constructed to represent laboratory informatics functionality independent of any single vendor's product categories or marketing language. Its construction rests on two foundations:
- Governing standards. ASTM E1578 (Standard Guide for Laboratory Informatics, covering LIMS/LES/LIS/ELN/SDMS relationships and terminology), CLSI LIS08-A (clinical LIS functional requirements), CLSI AUTO08/LIS01/LIS02 and POCT1-A/IHE LAW/SiLA2 (instrument and middleware connectivity), NIH and academic ELN governance guidance, ISA-88 and USP <1058> (laboratory execution and batch/instrument qualification systems), 21 CFR Part 11 (FDA electronic records and electronic signatures), ISO/IEC 17025 (general requirements for the competence of testing and calibration laboratories), the OAIS Reference Model/PREMIS/FAIR Data Principles (scientific data management and digital preservation), ISO 15489 (records management), ISO 9001 (document control), and ISO 31000/COSO ERM/the OCEG GRC Capability Model (governance, risk, and compliance). Each standard was used the same way: read for the specific functional requirements, terminology, or constraints it places on a laboratory informatics system, then translated into one or more discrete, vendor-neutral function entries within the appropriate Feature Matrix category, rather than copied wholesale as a checklist. Appendix A lists this narrower set of standards alongside the category structure each most directly shaped. Appendix C documents the fuller sourcing base — over 130 regulations, accreditation requirements, and guidance documents — that LIMSWiki's own LIMSpec methodology draws on and that this matrix was cross-checked against category by category.
- Iterative structural review. Categories and individual functions were added over multiple review passes as gaps in the taxonomy were identified, continuing until further review stopped surfacing materially new functionality — indicating the matrix had reached practical completeness for the domain.
How This Matrix Is Used
To produce a vendor profile from this matrix, each of the 469 functions is evaluated against that vendor's own current product documentation, technical materials, and other publicly available sources, and assigned one status from the Scoring Rubric below. The resulting profile documents that vendor alone against the fixed matrix — it is not, and should not be presented as, a comparison against any other vendor. Two vendor profiles produced from this same matrix can be read side by side precisely because both were scored against identical functions using an identical rubric — not because either vendor was evaluated relative to the other.
Nothing in this document constitutes an assessment of any company, product, or vendor. It defines the 469 functions that a completed vendor profile would be scored against, and the rubric used to score them. It contains no claims about what any particular vendor does or does not support.
Vendor Neutrality, AI Authorship & Independence
This section states plainly who produced this document, how, and under what constraints — so that the Feature Matrix and every profile built from it can be evaluated on those terms.
The LIMSpec Is a LabLynx Creation
LIMSpec, and the LiMSwiki.org platform on which it is published, were developed by LabLynx, Inc. as a community initiative for the laboratory informatics profession. LabLynx built both the wiki and the underlying Feature Matrix methodology because the industry lacked a shared, vendor-neutral reference for comparing LIMS, LIS, ELN, SDMS, and related systems on functional terms rather than marketing language — every vendor described its own product differently, in its own terminology, making even basic side-by-side comparison difficult for anyone evaluating software from outside a single vendor's own sales process.
LabLynx created LIMSwiki and LIMSpec together as an open, joint community effort rather than a closed or proprietary comparison tool, on the premise that laboratories, researchers, and procurement teams make better software decisions when they have access to open information and full transparency about what a system actually does — documented against a fixed, independently defined standard, not a vendor's own claims alone. The editorial and evidentiary independence described throughout the rest of this section — vendor-neutral construction, evidence-based status assignment, fully disclosed methodology — governs how LIMSpec is applied to every vendor equally, including LabLynx's own profile in this series.
The underlying premise is straightforward: informed, educated buyers have the most success with the software they choose. A shared, open information model that lets every laboratory informatics vendor be evaluated against the same functional matrix serves that goal directly, regardless of which single company originally built the tool that made it possible.
Vendor-Neutral by Design
The Feature Matrix defined in this document was constructed to represent the complete functional scope of laboratory informatics as an industry domain — not the feature set, terminology, or marketing framing of any single company. No vendor commissioned, funded, previewed, or influenced the selection, wording, or organization of the 469 functions or 28 categories in this matrix. The matrix does not favor the architecture, terminology, or product strategy of any particular vendor over another; where a function reflects terminology closely associated with one vendor's marketing (for example, agentic AI orchestration or a specific data-interchange standard), it was included because it represents a genuine, independently identifiable capability class in the broader market — not an endorsement of the vendor that popularized the term.
AI Authorship
This document, the underlying Feature Matrix, and every vendor profile produced from it are researched and written by Claude, an AI system developed by Anthropic. The standards research, category and function definitions, scoring rubric, and — in a completed vendor profile — the evidence gathering and status assignments for that vendor, are Claude's own work product, produced through direct research against publicly available standards documents, vendor materials, and independent sources. No human author drafted, rewrote, or supplemented the substantive content of this document or of any profile produced from it prior to publication.
As an AI-generated document, this matrix and any profile produced from it reflect Claude's interpretation of publicly available standards and materials as of the time the research was conducted. Readers are encouraged to verify all standards citations and, in a completed vendor profile, all vendor-specific claims directly against primary sources before relying on them for a purchasing, compliance, or research decision.
Objectivity Through Disclosed Method, Not Claimed Authority
This document does not ask to be trusted on the basis of expertise or authority. It asks to be checked. Every function in the Feature Matrix is traceable to a named standard or category of standards (Appendix A). Every status in a completed vendor profile is traceable to a specific source, documented against that function. Claude applies the same rubric, the same category structure, and the same evidentiary standard — evidence specific to the vendor in question, or the function is marked Not Supported — to every vendor profiled. This consistency of method, not any claim of neutrality on Claude's part, is what this document offers as its basis for being read as objective.
Scoring Rubric
When this matrix is applied to a specific vendor, each function is assigned one of the four statuses below, based on that vendor's own documentation and other publicly available materials.
| Status | Meaning | Points |
|---|---|---|
| ✓ Off-the-Shelf | Feature is included and works as described by the vendor in the LIMSpec for that item; no configuration or customization needed — it just works off the shelf. | 1 |
| ⚙ Configurable | Feature is included but requires configuration through software settings to work as expected; does not require developer coding. | 1 |
| ½ Extensible | Base feature exists but requires some coding or development to make it work as expected; will not affect the vendor's ability to stay on a COTS version and maintain its upgrade/support path. | 0.5 |
| ✕ Not Supported | Feature is not part of the system but this does not preclude it being added as a custom feature; the vendor must address whether custom features are possible. | 0 |
A category score is the sum of points earned across the functions in that category (Off-the-Shelf and Configurable each contribute 1 point, Extensible contributes 0.5 point, and Not Supported contributes 0). An overall vendor score is the total of these points summed across all 469 functions. Every function is weighted the same way regardless of category; no category itself is weighted more heavily than another.
A score produced using this rubric measures how much of the Feature Matrix a vendor's public documentation confirms — not how good, complete, or suitable that vendor's product is for any particular buyer. Many functions in this matrix are highly specialized (e.g., hospital core-lab features, biobanking-specific tooling, R&D chemistry/biology registration systems, agentic-AI orchestration) and fall outside the stated target market of many vendors entirely. A lower score in a specialized category is not evidence of a weaker product for buyers who do not need that specialization.
Vendor Profile
Corporate background and product line for the vendor this profile is applied to, as stated in the vendor's own materials and independently verified public sources. This master edition ships blank — click Edit on any row below to fill it in.
Vendor/Product LIMSpec Score
The Vendor/Product LIMSpec Score is the sum of points earned for this vendor across every category in this profile — all 28 Feature Matrix categories plus any categories added in Chapter 29 (Vendor Added Categories). Off-the-Shelf and Configurable each contribute 1 point, Extensible contributes 0.5 point, and Not Supported contributes 0. Every function is weighted the same way regardless of category, so the score rises automatically as functions are marked Off-the-Shelf, Configurable, or Extensible and falls if any are changed back to Not Supported. Current score: 237.5
| Attribute | Detail | |
|---|---|---|
| Vendor / Product | LabLynx / LabLynx One | |
| Headquarters | LabLynx, Inc., Pensacola, Florida, USA (per reviewed source documentation — note: this conflicts with other known references to Atlanta/Smyrna, Georgia; recommend the vendor confirm the correct current HQ address before this profile is finalized or published). | |
| Ownership | Privately held. | |
| Founded | Not stated in the documentation reviewed for this profile. | |
| Team composition | Not stated in the documentation reviewed for this profile. | |
| Core platform philosophy | LabLynx One is presented as a single underlying platform — built on the open-source eLabFTW ELN engine (Experiments, Resources, Teams, custom metadata fields, e-signatures, a RESTful API) — reconfigured, renamed, and where needed extended with purpose-built plugin apps into twelve functionally distinct “modules,” each operating as its own Team, rather than twelve separate point-solution products. The stated goal is one login, one audit trail, one permissions model, one API, and one unlimited-user license underneath every module a lab runs. | |
| Named applications | LabLynx One (core platform, delivered as twelve Team-based modules: Dashboard, LIMS, LIS, LES, ELN, Logbooks, Training Tracking, Document Management, Quality Management, Instrument & Asset Management, Inventory Management, Lab Portal). Add-on applications: LabDrive (Scientific Data Management System / document collaboration), LabVia (instrument integration/automation platform, comprising LabVia Hub and LabVia Cloud), LabGRC (Governance, Risk & Compliance, built on the Eramba framework), LabCourses (full learning management system), and LabCRM (client relationship management — per the source documentation, this is explicitly a newer, not-yet-fully-specified addition, positioned at a scoping level rather than a finalized product). | |
| Deployment options | Exactly two deployment models, per the reviewed documentation: sciCloud.net® (LabLynx-managed cloud, AWS-based, the standard deployment for all clients) and LabServer (on-premises/self-hosted, including air-gapped environments, using Docker Engine + Docker Compose on Ubuntu Server 24.04 LTS with a MySQL 8.4 database). No third “client-hosted cloud” option exists. | |
| Licensing model | Unlimited users per instance under a single server-based commercial subscription license (LabLynx, Inc.) — not per-seat pricing. The add-on applications (LabDrive, LabVia, LabGRC, LabCourses) are each separately licensed, optional annual subscriptions, also described as including unlimited users consistent with the platform-wide model. LabCRM licensing terms are described as still to be confirmed with LabLynx sales. The underlying eLabFTW platform itself is separately licensed under AGPL-3.0 (open source); LabLynx's commercial subscription layers hosting, branding, support, and proprietary configuration/integration on top of that open-source core without altering its licensing terms. | |
| Pricing (commercial) | Not addressed in the documentation reviewed for this profile — the vendor's own Security & Compliance Guide explicitly states pricing is excluded from that document and directs readers to elabeln.com/pricing. Per standing instruction, LabLynx One pricing/licensing figures should be re-verified directly with LabLynx before being quoted in any client-facing content. | |
| Compliance & standards support | 21 CFR Part 11 (native e-signatures, audit trail, RFC 3161 timestamping); ALCOA+ data integrity principles; NIST SP 800-53 Rev. 5 via Virginia ITRM Standard SEC530 (independently audited annually by Trustnet, Inc.); HIPAA (LabLynx acts as a Business Associate); GDPR-aligned data handling; ISO 17025 / ISO 15189 / GMP / CLIA / CAP touchpoints addressed at the module level (LIMS, LIS, LES, Quality Management, Instrument & Asset Management); a complete, pre-written IQ/OQ/PQ validation package aligned to GAMP 5 (Category 4 — Configurable Software) is provided to every customer; a published VPAT 2.5 Accessibility Conformance Report documents partial WCAG 2.1 AA / Section 508 conformance with a remediation roadmap; a pre-filled HECVAT 4.1.5 vendor-risk questionnaire is maintained. SOC 2 Type 2 is in progress (engagement with Saltmarsh CPAs); ISO/IEC 27001:2022 and FedRAMP are on the stated roadmap but not yet achieved. | |
| Security architecture | Hosted on AWS (US East/West) under a documented shared-responsibility model: AWS provides SOC 2/SOC 3-certified physical/hypervisor/network-layer security (including DDoS protection, WAF, GuardDuty); LabLynx is responsible for IAM configuration, OS patching, application security (secure SDLC, OWASP Top 10 controls, annual penetration testing), RBAC, encryption key management, backup/recovery, and security training. AES-256 encryption at rest (AWS KMS) and TLS 1.2+ in transit. Dedicated single-tenant database architecture per organization on sciCloud.net (no shared database infrastructure between clients). Role-based access control at user/group/project/site levels; SAML 2.0 SSO (also referred to in the vendor's Security & Compliance Guide as "LabLynx OpenSocial") plus LDAP support; MFA enforceable at team or instance level; semi-annual access reviews. Hourly incremental and daily full backups with geographically distributed secondary storage; documented, tested RTO/RPO. | |
| Industries served | Per the vendor's own Solution Template Library (13 pre-assembled industry bundles): academic/research, agriculture testing, biobanking, clinical/diagnostic testing, CRO/CDMO, environmental testing, food & beverage safety testing, forensic case & evidence management, GMP manufacturing QC (pharma, medical device, cosmetics, dietary supplements), general manufacturing QC, pharmaceutical & biotech R&D, point-of-care testing, and used-oil/asset health testing. | |
| Notable web properties | www.lablynx.com (corporate); www.elabeln.com (LabLynx One product site; also referenced as the default login-URL domain, e.g., yourorganization.elabeln.com); support.lablynx.com (knowledge base). | |
| Support model | Tiered support included per subscription (support@lablynx.com); a named LabLynx account manager for strategic/roadmap discussions; structured onboarding consultations (configuration review, template design assistance, user training, workflow setup); a searchable self-service knowledge base. Phone support line referenced in the vendor's Security & Compliance Guide: 866-522-5969 (866-LabLynx). | |
| Link to Vendor LIMSpec | Not yet documented |
Vendor Profile precedes the functional matrix chapters in every vendor-specific edition so that a reader has basic corporate context — who the vendor is, how long they've operated, what they call their products — before encountering 469 individual function-by-function status determinations. Like every other claim in a completed profile, the facts in this chapter should be sourced against the vendor's own materials.
Sample & Specimen Management
21 functions defined in this category. Vendor score: 12 / 21 (57.1%) — 0 Off-the-Shelf, 9 Configurable, 6 Extensible, 6 Not Supported.
Sample and specimen management governs everything that happens to a physical sample from the moment it enters a laboratory's custody until its final disposition. This category defines the foundational transactions every other laboratory function ultimately depends on: accessioning, labeling, chain-of-custody tracking, aliquoting, batch and worklist organization, status and lifecycle tracking, and retention or disposal scheduling. Because virtually no downstream test, result, or report can exist without a properly identified and tracked sample, gaps here tend to surface as data-integrity and traceability problems everywhere else in the system. In day-to-day operations, this category determines how quickly and accurately samples move from receipt through preparation to testing, how confidently a lab can prove what happened to a given specimen if a result is ever challenged, and how well the system scales as sample volume grows. Its importance is universal across laboratory types, but the specific functions that matter most vary by discipline — chain-of-custody rigor dominates in forensic and regulated testing, while pre-registration and self-service submission matter more to high-volume commercial and clinical reference labs serving external clients.
- ⚙Sample/specimen accessioning
- ½Barcode/label generation & scanning
- ½Chain-of-custody tracking
- ✕Chain-of-custody transfer tracking to external/outside entities for regulated samples (select agent, cannabis, etc.) with certification numbers
- ✕RFID-based sample/specimen identification (in addition to barcode)
- ½Automated/triggered sample pre-registration (date, time, web-request, or API-initiated)
- ½Sample receipt variance checking against customer/lab sampling requirements (general-purpose, all industries)
- ⚙Location/industry-specific safety information display upon sample registration
- ⚙Automatic sample-number generation for calibration, validation, and maintenance activities
- ✕Sample splitting / aliquoting
- ½Batch / worklist management
- ⚙Sample status/lifecycle tracking
- ✕Multi-site sample transfer/routing
- ⚙Sample re-test/re-sample workflow
- ⚙Sample scheduling (recurring/routine)
- ⚙Container/vessel tracking
- ⚙Sample disposal/retention tracking
- ½Client sample submission (self-service)
- ✕Sample lineage/genealogy tracking (parent-child/derivative sample relationships)
- ⚙Sampling site master list management (site codes, demographics, commodity/substrate association, active/inactive status)
- ✕Environmental monitoring program for production/cleanroom facilities (scheduled site testing, offsite/randomized sampling)
Case & Project Management
19 functions defined in this category. Vendor score: 6 / 19 (31.6%) — 0 Off-the-Shelf, 5 Configurable, 2 Extensible, 12 Not Supported.
Case and project management organizes laboratory work around a legal case, research study, or client-funded project rather than around individual samples alone, reflecting how forensic, medical examiner, and contract research operations actually function day to day. This category covers case-centric workflows, multi-discipline routing, project-based sample grouping, workload balancing and scheduling, legal hold and evidence-integrity controls, and independent case review. In practice, it determines whether a laboratory can coordinate work across multiple analysts, disciplines, or departments on a single matter without losing track of accountability, and whether it can defend that work if results are later scrutinized in court, an audit, or a client dispute. For forensic and medical examiner laboratories, functions like legal hold, destructive-testing authorization, and examiner testimony tracking are essential compliance infrastructure. For contract research organizations and academic core facilities, project-based grouping and workload management drive operational efficiency and client billing accuracy. General-purpose clinical or industrial labs typically use a narrower slice of this category, since not all of their work is organized around discrete legal or sponsor-funded matters.
- ⚙Case-centric workflow (forensic/legal)
- ✕Multi-discipline case routing
- ✕Medical examiner case management
- ⚙Project-based sample grouping (CRO model)
- ⚙Cross-team/cross-department data segregation
- ⚙External lab referral tracking
- ½Analyst workload balancing & case assignment dashboard
- ✕Personnel-to-task scheduling and allocation tools (staffing/instrument resource planning)
- ✕Personnel workload capping (limit samples/hours per analyst per sample type, e.g., cytology slide caps)
- ✕Automated workload-leveling task release (lean laboratory workflow balancing)
- ½Kanban-style task board visualization for workflow/status tracking
- ⚙Investigation linkage to case/sample
- ✕Cross-facility sample sharing / single accession across multiple labs (no duplicate login)
- ✕Legal hold / evidence integrity controls
- ✕Destructive testing authorization gate for evidence (prevent testing until documented approval)
- ✕Periodic independent case review scheduling (administrative/technical review by uninvolved personnel)
- ✕Examiner testimony documentation and periodic evaluation tracking
- ✕Investigational product (drug/blood product/medical device) chain-of-custody tracking for clinical trials
- ✕Assignment of unique entity identifiers (NPI/ORI) to enacting/subcontracted entities, appearing on records/reports
Test, Method, Specification & Limits Management
16 functions defined in this category. Vendor score: 12 / 16 (75.0%) — 0 Off-the-Shelf, 11 Configurable, 2 Extensible, 3 Not Supported.
This category defines how a laboratory manages the analytical methods it performs and the specifications a result must meet to pass. It covers method library management, specification and limits versioning, automated pass/fail comparison, out-of-trend detection, multi-tier specification approval, reflex testing rules, method validation linkage, calculation engines, and unit and significant-figure handling. These functions sit at the core of every quantitative and qualitative test a laboratory runs, since a result is only meaningful when it can be automatically and correctly evaluated against the right version of the right specification. Operationally, this category is what allows a lab to apply the same method and criteria consistently across every analyst and every sample, catch developing problems before they become outright failures, and demonstrate during an audit that every specification change went through proper review. Its influence is broadest in regulated and accredited testing environments — pharmaceutical, clinical, and environmental labs in particular — where inspectors specifically look for evidence that testing was performed against the currently approved method and specification version, with a documented history of every prior revision.
- ⚙Method library management
- ⚙Specification/limits versioning
- ½Automated pass/fail comparison to spec
- ⚙Product/method-linked specification sets
- ✕Out-of-trend (OOT) detection
- ⚙Multi-tier specification approval workflow
- ✕Reflex/conditional testing rules
- ⚙Method validation documentation linkage
- ⚙Calculation engine (result derivation)
- ⚙Multi-data-type result field support (numeric, text, date, list, file, calculated, Boolean, interval)
- ½Qualifier/operator entry with numeric results (<, >, ±)
- ⚙Bulk manual result entry via spreadsheet upload (non-instrument-sourced)
- ✕Configurable significant-figures/rounding-rule definition for reported numeric results
- ⚙Units of measure & unit conversion
- ⚙Limit of Detection (LOD) / Limit of Quantitation (LOQ) tracking per method
- ⚙In-process manufacturing material sample flagging and quality-attribute tracking (identity, strength, quality, purity)
Laboratory Execution System (LES)
15 functions defined in this category. Vendor score: 8 / 15 (53.3%) — 0 Off-the-Shelf, 5 Configurable, 6 Extensible, 4 Not Supported.
A Laboratory Execution System actively directs how a procedure is carried out in real time, rather than simply documenting it afterward. This category covers guided step-by-step execution, electronic batch records, yield and hold-time tracking, in-process e-signoff, deviation capture, equipment and reagent verification at point of use, real-time control-limit monitoring, and ISA-88-aligned recipe and equipment-state modeling. Its defining operational role is converting a paper batch record or SOP into an actively enforced digital procedure that prevents an operator from skipping steps, using unqualified equipment, or missing a required sign-off, catching problems while a process is still underway rather than after it is complete. This matters most in regulated manufacturing and complex multi-step analytical work — pharmaceutical batch production, sample preparation for regulated testing, and any process where sequence and completeness are themselves quality-critical. Laboratories performing straightforward, single-step bench testing without formal batch production generally have limited use for this category, while pharmaceutical, biotech, and other GMP manufacturers depend on it as core infrastructure for demonstrating that every batch was produced exactly as its approved procedure specifies.
- ½Guided step-by-step execution
- ⚙Electronic batch records
- ⚙Theoretical vs. actual yield calculation and recording across production phases
- ½Inter-process time tracking (production process timing/hold-time monitoring)
- ½In-process e-signoff at each step
- ½Deviation capture during execution
- ½Equipment/reagent verification at point of use
- ½Real-time in-process control limits
- ⚙Paperless work-instruction display
- ⚙Execution audit trail (who/what/when)
- ✕ISA-88 recipe hierarchy support (General/Site/Master/Control recipe levels)
- ✕ISA-88 equipment/phase state model with mode/state management and interlocks
- ✕USP <1058> analytical instrument/software qualification categorization (Group A/B/C)
- ⚙Recipe versioning with phase-level change control and impact analysis
- ✕Weigh & dispense integration with tolerance/limit checking
Electronic Lab Notebook (ELN) Core
26 functions defined in this category. Vendor score: 19 / 26 (73.1%) — 16 Off-the-Shelf, 3 Configurable, 0 Extensible, 7 Not Supported.
The Electronic Lab Notebook Core category defines the primary digital record of what a scientist actually did in an experiment and why — the direct replacement for a paper notebook page. It includes rich-text documentation, structured metadata fields, protocol checklists with timestamped execution, file attachments, template libraries, version and revision history, electronic signatures, tagging and full-text search, collaboration and commenting, and specialized capabilities like code blocks, freehand sketching, and cryptographic timestamping for intellectual-property protection. Operationally, this is the single most universally used category in the entire matrix, since virtually every laboratory discipline needs some mechanism for narrative, attributable documentation of experimental work, however much that narrative is supplemented by structured data elsewhere. Its influence on day-to-day work is direct and constant: how easily a scientist can document an experiment, how reliably that record can later be searched, audited, or defended, and how well institutional knowledge survives staff turnover all depend on the depth and quality of ELN functionality. Regulated laboratories additionally depend on this category to meet electronic-record requirements around signatures, version history, and data integrity.
- ✓Rich-text experiment documentation
- ✓Structured/custom metadata fields
- ✓Protocol/step checklists with timestamped execution
- ✓Experiment-to-resource linking
- ✓File attachment support
- ⚙Template library (protocol standardization)
- ✓Version/revision history on entries
- ✓Electronic signature on entries
- ✓Tagging & full-text search
- ✓Comments/collaboration on entries
- ✓RFC 3161 / blockchain timestamping (IP protection)
- ⚙Multi-experiment hierarchy with genealogy/lineage tracking
- ✓LaTeX/equation rendering
- ✓Export to PDF / RO-Crate / interoperable format
- ✕Desktop application bridge for native file editing
- ✕Real-time collaborative multi-user notebook editing
- ✕Legacy paper record digitization workflow with mandated metadata capture
- ✓Automatic periodic autosave during data entry
- ⚙Structured data migration tooling from legacy ELN/paper/spreadsheet sources
- ✕File-level version history on individual attached files (distinct from body-text revision history)
- ✓Syntax-highlighted code block support within ELN entries (Python, R, bash, etc.)
- ✓Built-in freehand draw/sketch annotation tool within ELN entries
- ✕@Mention-style inline cross-referencing of inventory items, protocols, samples, or team members (live navigable link)
- ✕Direct JSON metadata editor for advanced/bulk metadata manipulation
- ✓One-click entry/template duplication retaining metadata and steps
- ✕Custom interactive widget/JavaScript builder embeddable within ELN entries (calculators, data capture forms, lookup tools)
Scientific Data Management (SDMS)
18 functions defined in this category. Vendor score: 10.5 / 18 (58.3%) — 1 Off-the-Shelf, 8 Configurable, 3 Extensible, 6 Not Supported.
Scientific Data Management covers how a laboratory captures, archives, and governs the raw data and documents its instruments and staff generate, independent of any single experiment record. This category includes raw instrument data capture, long-term archival separate from the operational database, instrument file-format parsing, document version control and SOP change control, metadata tagging, data-integrity checksums, and specialized long-term preservation standards such as OAIS and PREMIS for organizations with multi-decade retention obligations. Its operational role is preserving the primary evidentiary record behind every reported result and every controlled document, so that a calculated result or a current SOP can always be traced back to the original data or approved version that produced it. This matters for every laboratory to some degree, since ALCOA+ data-integrity principles specifically require original data to be preserved, but the depth of SDMS functionality needed scales sharply with data volume, instrument diversity, and retention duration — a lab with a handful of instruments and modest retention needs has far simpler requirements than one managing years of multi-instrument data under decades-long regulatory retention rules.
- ⚙Raw instrument data capture & archiving
- ✕Long-term data retention independent of operational DB
- ½Instrument file format parsing
- ⚙Centralized document/file repository
- ⚙Document version control
- ⚙SOP management with change control
- ½External BI tool integration (Power BI/Tableau)
- ✓Modern web-based SDMS interface
- ⚙Metadata tagging on archived data
- ⚙Data integrity checksums / tamper-evidence
- ⚙Image/photo capture & management (specimen/slide imaging)
- ✕OAIS-compliant digital preservation architecture (ISO 14721)
- ✕PREMIS preservation metadata support (ISO 22927 — technical/provenance metadata for long-term archival)
- ⚙FAIR data principles compliance framework (explicit Findable/Accessible/Interoperable/Reusable)
- ✕ISO 19115 / EPA Metadata Technical Specification compliance for environmental data publishing
- ✕Dedicated education/course-management module for teaching laboratory courses (assignments, grading, TA feedback, institutional LMS integration)
- ✕Direct integration with public research data repositories (e.g., Zenodo, Figshare, Dataverse, Dryad) for one-click dataset deposit
- ½Automated file watching/ingestion (hot-folder monitoring for automatic data capture)
Stability, Formulation & Batch Management
10 functions defined in this category. Vendor score: 7 / 10 (70.0%) — 0 Off-the-Shelf, 7 Configurable, 0 Extensible, 3 Not Supported.
This category supports laboratories that must demonstrate a product remains safe and effective throughout its shelf life, or that manage the formulation and batch-level production record behind a manufactured product. It covers stability protocol design, pulling-schedule automation, accelerated stability modeling, formulation and recipe management, batch-to-recipe linkage, batch release workflow to a Certificate of Analysis, and rework eligibility. Operationally, these functions govern long-running, multi-year testing programs and the formal decision gates that determine whether a batch can be released to a customer or must be reworked or rejected. This is essential, purpose-built functionality for pharmaceutical, biotech, food, and other regulated manufacturers running formal stability programs and batch production, where a missed pull date or an undocumented formulation change carries direct regulatory consequences. Laboratories that perform only analytical testing without manufacturing a formulated product, or that have no time-based shelf-life claims to support, will find this category largely inapplicable, making it one of the more industry-specific rather than universally relevant sections of the matrix.
- ⚙Stability protocol design
- ⚙Pulling schedule automation
- ✕Accelerated stability condition simulation
- ⚙Interval/cycle-based study lifecycle workflow
- ⚙Formulation & recipe management
- ⚙Batch-to-recipe linkage
- ⚙Batch release workflow to COA
- ✕Batch reprocessing/rework eligibility flagging and workflow
- ✕Legacy stability system data migration support
- ⚙Freeze/thaw cycle tracking (biobanking/bioanalytical samples)
Molecular Biology / Life Sciences Tools
27 functions defined in this category. Vendor score: 6 / 27 (22.2%) — 0 Off-the-Shelf, 6 Configurable, 0 Extensible, 21 Not Supported.
This category covers specialized bioinformatics and molecular biology capabilities that go well beyond general-purpose sample or experiment tracking: PCR and NGS workflow support, plasmid and sequence editing, plate management, compound and biological sequence registration, in silico cloning and PCR modeling, CRISPR guide design, structure prediction tools like AlphaFold integration, flow cytometry and mass spectrometry analysis, and in vivo animal study management. Its operational relevance is concentrated almost entirely in life-science research, biotech, and pharmaceutical discovery organizations, where these functions directly support the scientific work of designing genetic constructs, screening compounds, and analyzing complex biological data — work that a general-purpose LIMS or ELN data model cannot adequately represent on its own. For laboratories in these disciplines, the depth of molecular biology tooling can be a decisive platform differentiator, since it determines whether scientists can work entirely within one system or must constantly move data between the platform and separate specialized bioinformatics software. General clinical, environmental, industrial, and forensic laboratories typically have no use for this category, as it addresses a scientific domain distinct from their core testing work.
- ⚙PCR/NGS workflow support
- ✕Plasmid/sequence map editor
- ⚙Plate management (96/384-well)
- ⚙Reagent lot traceability (molecular)
- ✕High-complexity testing documentation
- ✕Genomics/proteomics data handling at scale
- ⚙Chemical/molecular structure capture within ELN
- ⚙Chemical structure drawing, rendering & structure-based search
- ⚙Compound/chemical registration system (unique ID assignment, structure-based)
- ✕Biological sequence/construct registration system
- ✕High-throughput screening (HTS) assay data management
- ✕CRISPR guide design & genome browsing tools
- ✕Multiple sequence alignment (DNA/RNA/amino acid) with consensus generation
- ✕In silico restriction enzyme digest modeling (cut site/fragment prediction)
- ✕In silico multi-fragment cloning strategy modeling (Gibson Assembly, Golden Gate)
- ✕In silico PCR amplification modeling (primer binding verification, product prediction)
- ✕Codon optimization for target organism expression
- ✕NCBI BLAST integration for sequence homology searching
- ✕AlphaFold / protein 3D structure prediction integration
- ✕Flow cytometry data analysis tools (FCS file capture, gating, visualization)
- ✕Mass spectrometry / proteomics analysis tools (peptide/protein identification, quantification, PTM analysis)
- ✕In vivo animal study design and management module (multi-arm treatment groups, timepoints, endpoint tracking)
- ✕Multi-parameter animal randomization algorithms for eliminating group-assignment bias
- ✕In vivo study real-time analytics (body weight change, nadir calculations, survival analysis)
- ✕Bioprocess / process development study tools (recipe execution, assay runs, biomanufacturing workflows)
- ✕Antibody / peptide bioinformatics (BCR/TCR/VHH/scFv sequence analysis)
- ✕HGVS (Human Genome Variation Society) nomenclature support for sequence variant reporting
Instrument & Equipment Integration
25 functions defined in this category. Vendor score: 9 / 25 (36.0%) — 0 Off-the-Shelf, 4 Configurable, 10 Extensible, 11 Not Supported.
This category defines how a laboratory's instruments connect electronically to its information systems, covering bidirectional result transmission, autoverification, HL7/ASTM and modern connectivity standards like SiLA 2, worklist automation, calibration and maintenance scheduling, qualification records linkage, and centralized connectivity gateways for multi-vendor instrument fleets. Its operational impact is direct and substantial: reliable instrument integration eliminates manual transcription, one of the most well-documented sources of laboratory error, while enabling automation like rules-based result release that would be impossible if data required manual entry. Every laboratory generating instrument data benefits from this category to some degree, but its practical importance scales sharply with instrument count, sample volume, and fleet diversity — a lab with one or two instruments has comparatively modest integration needs, while a high-volume clinical or industrial laboratory operating dozens of different instrument models depends on broad driver support and centralized connectivity architecture to avoid a costly, ongoing custom-integration burden. Regulated laboratories also rely on this category to keep out-of-calibration instruments from being selected for use, a specific and frequently audited compliance control.
- ½Bidirectional instrument result transmission
- ✕Autoverification of instrument results (rules-based release without manual review)
- ½HL7/ASTM analyzer interface support
- ½Worklist download automation to instruments
- ½Middleware/driver library breadth
- ✕Chromatography Data System (CDS) integration
- ½Equipment calibration & maintenance scheduling
- ½Manual instrument data transfer elimination (auto-capture)
- ½Point-of-care (POC) device integration
- ⚙Instrument qualification records linkage
- ✕Real-time instrument status monitoring
- ⚙Instrument/equipment reservation and usage scheduling (booking system)
- ⚙Scheduled/automatic instrument online/offline state management
- ½Automatic prevention of instrument selection when out-of-calibration, overdue maintenance, or under investigation
- ⚙Calibration activity linkage to certified reference material/measurement standards
- ✕Parent-child instrument dependency management (auto-offline cascade for components)
- ✕Usage-count-based instrument event triggers (in addition to calendar-based scheduling)
- ½Closed-loop screening workflow (ELN/LIMS request automatically triggers an instrument run, with results parsed and returned without manual data transfer)
- ✕PubMed literature search/import integration for linking references to notebook entries
- ✕Cleanroom/pharma manufacturing instrument integration
- ✕SiLA 2 / modern open instrument connectivity standard support (plug-and-play discovery, streaming telemetry)
- ✕AnIML (Analytical Information Markup Language) data format support
- ✕Allotrope Data Format (ADF) support for vendor-neutral scientific data exchange
- ✕IHE LAW profile support (standardized plug-and-play multi-vendor instrument connectivity)
- ½Centralized instrument connectivity broker/gateway (multi-protocol translation hub)
Robotics, Automation & IoT
10 functions defined in this category. Vendor score: 1.5 / 10 (15.0%) — 0 Off-the-Shelf, 0 Configurable, 3 Extensible, 7 Not Supported.
This category covers physical automation and connected-sensor technology within the laboratory: liquid-handling robotics orchestration, robotic sample handling, automated data-workflow triggers, IoT-based environmental monitoring, predictive maintenance, automated reorder triggers, and installable automation modules. Its operational value centers on removing manual labor and manual error from high-volume, repetitive physical tasks and continuously monitoring conditions — like freezer temperature — that would otherwise depend on periodic manual checks. Laboratories with significant investment in liquid-handling automation, high-throughput screening, or large sample volumes benefit substantially, since these functions directly reduce both labor cost and the physical error risk associated with manual sample handling at scale. Environmental monitoring of temperature-sensitive storage in particular is close to a baseline expectation across nearly every laboratory type, since an unnoticed freezer failure can destroy irreplaceable samples within hours. By contrast, laboratories performing exclusively manual bench work without robotic equipment or IoT sensor infrastructure will find most of this category's more advanced functions, such as digital twin modeling or liquid-handler orchestration, of limited immediate relevance to their operations.
- ✕Liquid handler / robotics orchestration
- ✕Digital twin technology integration (predictive maintenance, real-time environmental modeling)
- ½Automated data workflow triggers
- ✕IoT/environmental monitoring integration
- ✕Robotic sample handling integration
- ½Automated reorder / procurement triggers
- ✕App package / installable automation modules
- ✕Predictive maintenance alerts (equipment)
- ✕Facility environmental/security monitoring integration (alarms, locks, doors) with notification and logging
- ½Environmental monitoring of sample-storage equipment (incubators, freezers) with automated alerting
Enterprise System Integration (ERP / MES / CDS / API)
14 functions defined in this category. Vendor score: 7 / 14 (50.0%) — 2 Off-the-Shelf, 3 Configurable, 4 Extensible, 5 Not Supported.
This category governs how a laboratory platform connects to the broader enterprise software ecosystem it operates within: REST APIs, ERP integration with systems like SAP, Manufacturing Execution System connectivity, Electronic Document Management System integration, webhook-based notifications, and pre-built third-party connector marketplaces. Its operational role is ensuring laboratory data doesn't exist as an isolated island, but instead flows into the financial, supply-chain, production, and document-control systems the rest of the organization already depends on. This matters most for larger organizations where the laboratory is one operational unit within a much larger enterprise, or for manufacturers whose lab testing directly gates a live production process and needs to communicate with plant-floor systems in near real time. A robust, well-documented API is foundational infrastructure here, since nearly every other integration in this category ultimately depends on the platform exposing a capable API other systems can build against. Smaller, independent laboratories without an equivalent enterprise-level ERP or MES ecosystem to integrate with will find comparatively less need for the deeper end of this category's capabilities.
- ✓REST API for external integration
- ½ERP integration (e.g., SAP)
- ½MES/PIMS integration
- ½EDMS integration
- ⚙Multi-server simultaneous API connections
- ✓Open API specification support
- ½Webhook-based event notification
- ✕Pre-built third-party connector marketplace
- ✕LIMS-to-LIMS data transfer / multi-lab federation
- ✕VETXML veterinary data interchange format support
- ✕FDA ORA DX (Office of Regulatory Affairs Data Exchange) file format support
- ⚙Selective data archiving by date/type criteria (choose which electronic data and metadata to archive)
- ⚙Configurable/extensible data schema (modify underlying data structures without vendor intervention)
- ✕BioTrack THC seed-to-sale integration (alongside/alternative to METRC)
AI, Machine Learning & Predictive Analytics
24 functions defined in this category. Vendor score: 2.5 / 24 (10.4%) — 0 Off-the-Shelf, 0 Configurable, 5 Extensible, 19 Not Supported.
This category captures how artificial intelligence and machine learning are applied within a laboratory platform, spanning embedded predictive analytics, conversational and agentic AI, anomaly and outlier detection, natural-language data querying, AI-assisted documentation and configuration, machine-learning-based QC rule tuning, and specialized applications like image-integrity verification and supply forecasting. Operationally, these functions aim to shift laboratory management from reactive to proactive, surfacing developing problems before they become failures and reducing the manual effort behind routine tasks like documentation drafting or QC review. Its practical value depends heavily on data volume and history, since most of these capabilities are genuinely predictive rather than merely automated, and models need sufficient historical data to learn meaningful patterns. This is a rapidly evolving area across the industry, and laboratories evaluating a platform on this category should weigh not just which AI functions exist, but how mature, transparent, and auditable the underlying implementation actually is — a consideration with particular weight in regulated laboratories, where relying on an unexplainable AI-driven decision can itself become an audit finding independent of whether the output was accurate.
- ½Embedded predictive analytics
- ½Conversational AI / digital assistant for lab operations
- ✕Agentic AI workflow orchestration (autonomous multi-step task execution)
- ✕AI-assisted no-code/low-code configuration (natural language to workflow/code generation)
- ½Anomaly/outlier detection (AI-driven)
- ½Natural language data query/interaction
- ✕AI-assisted documentation/notebook authoring
- ½AI-driven scheduling/resource optimization
- ✕Machine-learning-based QC rule tuning
- ✕AI-powered audit trail analysis
- ✕Automation of manual instrument data transfer (AI/partnership-driven)
- ✕Vendor-published AI roadmap/positioning
- ✕AI model transparency / explainability documentation
- ✕Ontology-based machine learning for laboratory dataset analysis
- ✕AI-driven autonomous customization of data aggregation/transformation/reporting based on learned patterns (no explicit instruction)
- ✕AI-driven operational parameter monitoring (capacity utilization, data integrity risk) with proactive notification and logging
- ✕AI-powered conversion of PDF SOPs or text prompts into structured, importable protocol templates
- ✕Direct export/integration with dedicated statistical graphing software (e.g., GraphPad Prism)
- ✕Structure-activity relationship (SAR) / cheminformatics data visualization (compound properties vs. biological activity plotting)
- ✕Natively integrated full-featured statistical analysis / publication-quality graphing software (no data export required)
- ✕AI-powered scientific image integrity verification (detecting manipulated or duplicated images) for research-integrity screening
- ✕AI-powered supply/consumable forecasting predicting stockouts from historical usage patterns
- ✕AI-generated experimental write-up/summary from raw data
- ✕Autonomous/agentic AI review-by-exception for QC results
Mobile, Remote Access & Multi-Site Operation
9 functions defined in this category. Vendor score: 5 / 9 (55.6%) — 2 Off-the-Shelf, 3 Configurable, 0 Extensible, 4 Not Supported.
This category addresses how laboratory staff access the platform away from a fixed desktop workstation and how the platform supports operations spanning multiple physical locations: mobile-responsive web access, native mobile applications, camera and GPS-based field data capture, offline data collection, multi-site configuration, and time-zone handling. Its operational relevance depends heavily on how a laboratory's actual work is distributed. Field-based programs — environmental monitoring, agricultural sampling, point-of-care testing — depend on offline capability and mobile data capture to function at all in locations with unreliable connectivity. Organizations spanning more than one physical facility need multi-site configuration and cross-time-zone handling simply to operate coherently as a single entity rather than a collection of disconnected instances. Laboratories operating from a single fixed location with all work performed by staff at desktop or bench workstations will find much of this category's field-oriented and multi-site functionality unnecessary, while any laboratory whose staff occasionally need to check status or review results away from their desk benefits at least from basic mobile-responsive access.
- ✓Mobile-responsive web access
- ✕Native mobile application
- ⚙Camera/barcode scanning + GPS field data capture (mobile)
- ✕Remote/offline data collection
- ⚙Multi-site/multi-lab configuration
- ✓Multi-tenant enterprise scalability
- ✕Cross-site data roll-up reporting
- ⚙Time-zone/multi-region support
- ✕Voice command / hands-free lab interaction
Inventory, Reagent & Asset Management
17 functions defined in this category. Vendor score: 11.5 / 17 (67.6%) — 0 Off-the-Shelf, 10 Configurable, 3 Extensible, 4 Not Supported.
This category manages the reagents, consumables, and equipment a laboratory consumes and relies on to operate: inventory tracking, multi-location storage, automated reorder triggers, receiving inspection, lot and expiration tracking, standard re-standardization, hazardous-material flagging, vendor approval validation, and quarantine workflows pending QC release. Its operational importance is close to universal, since virtually no laboratory operates without consuming reagents as part of routine testing, and poor inventory visibility reliably produces avoidable problems — unexpected stockouts that halt testing, expired reagents used unknowingly, and wasted material from overstocking. Lot and expiration tracking in particular underpins result validity across every discipline, since a result generated with an expired or unqualified reagent lot is a documented data-integrity concern regardless of testing type. Regulated manufacturing and testing environments additionally depend on this category's more formal controls — vendor approval gating, incoming material quarantine, hazardous-material classification — as auditable evidence that materials entering the laboratory were properly vetted before use, making this category as much a quality-system component as an operational convenience.
- ⚙Reagent/consumable inventory tracking
- ⚙Multi-location storage management
- ½Automated reorder point triggers
- ✕Third-party inventory marketplace/procurement platform synchronization (e.g., Quartzy)
- ⚙Supplier/vendor management
- ⚙Receiving inspection workflow
- ⚙Lot/expiration tracking
- ✕Standard/reagent re-standardization and revaluation tracking (assign new standard value after restandardization)
- ⚙Hazardous/controlled/regulated material flagging based on physical/chemical stability classification
- ⚙In-house standard/volumetric solution tracking (concentration, purity, molarity factor) for calculation use
- ✕Vendor master list with approval status for inventory order validation
- ⚙Material quarantine workflow pending QC validation or disposal
- ✕Prevention of reagent/standard usage that would expire during the course of testing (mid-test expiration check)
- ⚙Equipment/asset registry
- ½Calibration/maintenance event scheduling
- ⚙Storage location hierarchy (freezer/rack/box/position)
- ½Barcode-driven inventory transactions
Document Management & Control
16 functions defined in this category. Vendor score: 7 / 16 (43.8%) — 1 Off-the-Shelf, 6 Configurable, 0 Extensible, 9 Not Supported.
This category governs how a laboratory manages its controlled documents — SOPs, specifications, policies, and records — through their complete lifecycle from drafting to retirement: version-controlled repositories, approval workflows, SOP change control, records retention and disposition, document search, and integration with desktop office applications and open-access protocol repositories. Its operational role is ensuring every laboratory employee always works from the current, formally approved version of a document, and that superseded versions remain available for historical reference rather than being lost or, worse, mistakenly followed. This is foundational infrastructure for every laboratory maintaining any controlled documentation, but the compliance stakes rise sharply in regulated environments, where working from an outdated procedure version is a well-documented and specifically audited category of laboratory error. As document repositories grow over months and years, the value of strong search and retrieval capability compounds, since a large, poorly searchable archive of historical SOPs and records becomes progressively less useful even though the underlying documents remain technically preserved.
- ⚙Version-controlled document repository
- ⚙Document approval workflows
- ⚙SOP change control
- ⚙Centralized protocol repository (team vs personal)
- ✕Controlled document distribution/read receipts
- ⚙Records retention policy enforcement
- ✓Document search across repository
- ✕File format flexibility (native app editing bridge)
- ✕Records disposition scheduling with automated destruction/transfer workflow (ISO 15489-aligned)
- ✕Document authenticity/reliability/integrity metadata per ISO 15489
- ✕Desktop application bridge allowing attached files to be opened/edited in native desktop apps with automatic save-back to the platform
- ✕Real-time Microsoft Office Online co-authoring (Word/Excel/PowerPoint) natively within the platform
- ✕Direct import from open-access protocol repositories (e.g., protocols.io)
- ✕Native SQL-queryable data warehouse spanning all platform data for advanced analytics
- ✕DOI (Digital Object Identifier) assignment and direct open-data publishing from within the platform
- ⚙SOP/method revision linkage to specific tests performed using that revision
Learning & Competency Management (LMS)
10 functions defined in this category. Vendor score: 8 / 10 (80.0%) — 0 Off-the-Shelf, 7 Configurable, 2 Extensible, 1 Not Supported.
This category tracks staff training, qualification, and ongoing competency — verifying not just that a procedure exists, but that the person performing it has been properly trained and remains current on the methods and equipment they use. It typically includes training assignment and completion tracking, competency assessment scheduling, certification expiration alerts, and linkage between training records and the specific SOPs or methods they cover. Operationally, this category matters because personnel qualification is a foundational, frequently audited element of any laboratory quality system — a technically correct procedure performed by an inadequately trained analyst is still a quality risk, and regulators specifically expect documented evidence connecting a person's qualifications to the work they are authorized to perform. This is essential in every accredited or regulated laboratory environment, where training records are a routine, specific focus of external inspections, and increasingly valuable even in unregulated research settings as a way to ensure consistent, competent execution across a growing or rotating staff. Laboratories with very small, stable, informally managed teams may find a lighter-weight approach to this category sufficient.
- ⚙Dedicated LMS module
- ⚙Training assignment & tracking
- ⚙Competency assessment documentation
- ⚙Annual re-certification workflow
- ⚙Self-service onboarding content hosting
- ⚙Regulatory training linkage (GLP/safety)
- ✕Infrequent-test competency verification tagging/alerting (additional validation required before performing rarely-run tests)
- ⚙Batch/bulk personnel data modification tools
- ½Analyst method-specific qualification/authorization tracking (gating workflow access)
- ½Training matrix report showing personnel-to-competency/certification mapping
Client / Patient / Physician Portal & Collaboration
8 functions defined in this category. Vendor score: 5 / 8 (62.5%) — 1 Off-the-Shelf, 1 Configurable, 6 Extensible, 0 Not Supported.
This category provides external stakeholders — clients, patients, or referring physicians — with a self-service window into the laboratory's work, without requiring laboratory staff to manually relay every status update or result. It typically covers order submission portals, result and report delivery, status inquiry dashboards, and secure messaging or collaboration features between the laboratory and its external parties. Operationally, a strong portal reduces the administrative burden of fielding routine status inquiries by phone or email, while giving clients and patients more visibility and control over their own orders and results. This is most valuable to laboratories serving external customers directly — commercial reference labs, clinical laboratories reporting to patients and physicians, and contract research organizations — where client-facing service quality is itself a competitive differentiator. Purely internal laboratories, such as an R&D lab serving only its own organization's scientists, have comparatively little use for this category, since all of their result recipients already have direct internal system access rather than needing an external-facing portal experience.
- ½Clinical physician ordering portal
- ½Clinical patient portal
- ½Internal lab portal (cross-department)
- ½CRO / external client portal
- ½Results/report access for external users
- ✓Messaging/team collaboration within platform
- ½Recurring test program self-scheduling (client-facing)
- ⚙GDPR-compliant client communications
Billing, Customer & Project Administration
8 functions defined in this category. Vendor score: 2.5 / 8 (31.3%) — 0 Off-the-Shelf, 2 Configurable, 1 Extensible, 5 Not Supported.
This category covers the business-administration side of laboratory operations: client account management, order and quote management, billing and invoicing tied to completed testing, and project-level cost tracking. Its operational role is connecting the scientific work a laboratory performs to the commercial relationship and financial transaction behind it, ensuring that completed testing translates accurately and efficiently into an invoice, and that client account information stays consistent across every order and interaction. This matters most for laboratories operating as a service business to external customers — commercial reference labs, contract research organizations, and any lab billing clients per sample or per project — where inaccurate or delayed billing directly affects revenue and client relationships. Laboratories performing exclusively internal work for their own parent organization, with no external client billing relationship to manage, will find this category largely inapplicable. Even among labs that do bill externally, the depth of functionality needed scales with the complexity of their pricing model and client base, from simple flat-rate billing to complex, project-based cost accounting.
- ⚙Customer/client record management
- ⚙Project setup & tracking
- ✕Test price list management
- ✕Invoice generation
- ½ERP billing system integration
- ✕Contract/pricing tier management
- ✕Quote/SOW review and approval workflow (CRO client-facing)
- ✕ICD-10 / billing code screening & automation
Business Intelligence, Dashboards & Reporting
27 functions defined in this category. Vendor score: 6 / 27 (22.2%) — 0 Off-the-Shelf, 2 Configurable, 8 Extensible, 17 Not Supported.
This category covers how a laboratory turns its accumulated operational and scientific data into visual insight: configurable dashboards, custom report generation, turnaround-time and productivity analytics, trend visualization, and integration with external BI platforms like Power BI or Tableau. Its operational value lies in making patterns and problems visible that would otherwise stay buried in raw transactional data — a slipping turnaround time, an underused instrument, a client whose order volume is quietly declining — well before they become obvious through anecdotal observation alone. Every laboratory benefits from at least basic reporting capability, but the sophistication needed scales with organizational size and complexity: a small lab may be well served by simple built-in reports, while a larger, multi-site organization often needs the deeper cross-departmental analytics and self-service report-building that dedicated BI integration provides. This category also underpins evidence-based management decisions and client-facing performance reporting, making the depth and flexibility of a platform's reporting and dashboard capability a meaningful factor in day-to-day operational visibility and long-term continuous improvement.
- ½Configurable role-based dashboards
- ✕Ad hoc query builder
- ½Custom report designer
- ½Trend/charting visualization
- ½KPI tracking (TAT, bottlenecks, OOS rate)
- ⚙Export to PDF/Excel/Word
- ✕SQL/data warehouse access for external BI tools
- ½Scheduled/automated report distribution
- ✕Control chart visualization
- ½Client-facing report/dashboard access
- ½Cross-module unified reporting (ELN+LIMS+QMS)
- ✕Regulatory submission report formats
- ✕Accreditation-status linkage controlling which accreditation labels/logos appear on reports (e.g., WADA, A2LA)
- ✕Proactive advance alerting for at-risk turnaround time (TAT) or likely OOS before results are finalized
- ⚙Amended/reissued report versioning with visible change flag and reason-for-change documentation
- ✕NPDES DMR (Discharge Monitoring Report) regulatory package (EPA)
- ✕EPA ASR, SEDD, and ERT electronic data exchange format support (environmental regulatory reporting)
- ✕Electronic Data Deliverable (EDD) validation linked to Quality Assurance Project Plan (QAPP)
- ✕Test utilization / necessity-checking analytics against established benchmarks
- ✕Laboratory utilization / test-ordering stewardship analytics
- ✕Test-based work capacity/throughput reporting and forecasting
- ✕Workflow/value-stream mapping with failure-point identification (lean/continuous-improvement tooling)
- ½Visual drag-and-drop workflow canvas showing linear/non-linear step relationships
- ✕Bottleneck/stalled-task detection based on inactivity duration thresholds
- ✕In-memory associative analytics engine (high-speed pattern/trend discovery)
- ✕Living knowledge graph for scientific data (contextualized cross-entity search)
- ✕Regulatory dataset assembly (CDISC SEND/SDTM)
Quality Management, CAPA & Investigation (OOS/OOT)
23 functions defined in this category. Vendor score: 15 / 23 (65.2%) — 0 Off-the-Shelf, 12 Configurable, 6 Extensible, 5 Not Supported.
This category manages a laboratory's formal quality system: deviation and nonconformance capture, out-of-specification and out-of-trend investigation workflows, corrective and preventive action (CAPA) tracking, root-cause analysis, and the documented linkage between an investigation and the sample, result, or process event that triggered it. Its operational role is ensuring that when something goes wrong — a failed result, a procedural deviation, a customer complaint — the laboratory has a structured, auditable process for investigating why, documenting the response, and verifying the corrective action actually resolved the underlying problem rather than merely addressing its symptom. This is essential infrastructure in every regulated laboratory, where a formal, functioning CAPA and investigation program is not merely good practice but typically an explicit, named accreditation or regulatory requirement, and where auditors specifically expect to trace an investigation back to its triggering event and forward to its verified resolution. Laboratories without formal accreditation still benefit from this category as a disciplined way to learn from and prevent recurrence of operational problems, though the compliance stakes are highest in accredited and regulated testing environments.
- ⚙Standalone QMS / document control module
- ✕Design Control Document / Device History File for medical device development (21 CFR 820.30)
- ✕Device Master Record (DMR) and Device History Record (DHR) management (21 CFR 820.181/184)
- ⚙Product recall tracking and reconciliation (distributed vs. recovered quantities by lot/batch)
- ⚙HACCP/food safety plan development and Critical Control Point (CCP) workflow implementation
- ⚙CAPA workflow
- ⚙Non-conformance/deviation management
- ⚙Dedicated OOS investigation module
- ⚙Root cause analysis documentation
- ½CAPA effectiveness verification and recurrence tracking (curbing repeat incidents)
- ✕Animal research subject tracking (acquisition, disposition, euthanization, welfare records, USDA licensing)
- ⚙Internal audit program management
- ½Compliance checklist management (CAP/CLIA/ISO)
- ½Risk assessment documentation
- ½Risk register with configurable likelihood/impact scoring methodology (ISO 31000-aligned)
- ½Control library with cross-framework mapping (single control satisfies multiple regulatory frameworks)
- ✕Key Risk Indicator (KRI) tracking and risk tolerance threshold alerts
- ✕Third-party/vendor risk management (supplier assessment, onboarding, ongoing monitoring)
- ½Governance/risk/compliance (GRC) framework
- ⚙Proficiency testing management
- ⚙QC sample type configuration (MB/MS/MSD/LCS)
- ⚙Change control workflow
- ⚙Customer/client complaint logging, investigation & trend reporting
Statistical Process / Quality Control (SPC/SQC)
6 functions defined in this category. Vendor score: 1 / 6 (16.7%) — 0 Off-the-Shelf, 0 Configurable, 2 Extensible, 4 Not Supported.
This category applies statistical methods to ongoing quality control data — control charts, Westgard-style multi-rule QC evaluation, control limit calculation, and trend analysis across QC runs — to distinguish normal method variability from a genuine, actionable shift in performance. Its operational purpose is catching a drifting instrument or degrading method before it produces a batch of invalid patient or product results, using statistically grounded rules rather than relying on an analyst's subjective judgment about whether a QC result looks acceptable. This is especially well-established and valuable in high-volume clinical chemistry and similar disciplines with long, continuously run QC histories, where the underlying statistical rules were largely developed and validated, but the same principles apply to any laboratory running repeated QC measurements over time on a stable method. Smaller laboratories, or those with limited QC history and low testing volume, may find the full sophistication of formal SPC/SQC rule sets less immediately necessary than larger, high-throughput operations where subtle statistical drift can otherwise go unnoticed until it produces an outright failure.
- ✕Control chart generation
- ✕Rule-based violation detection (Westgard-style)
- ✕Trend/shift/drift alerting
- ✕Statistical calculation engine (Cpk, Ppk, etc.)
- ½Third-party statistical engine integration
- ½QC sample trending across time/instrument/analyst
Electronic Signatures, Audit Trail & Validation
20 functions defined in this category. Vendor score: 16.5 / 20 (82.5%) — 13 Off-the-Shelf, 3 Configurable, 1 Extensible, 3 Not Supported.
This category provides the electronic-record backbone that regulated laboratory data integrity depends on: 21 CFR Part 11-compliant e-signatures, multi-level signature workflows, immutable and tamper-evident audit trails, revision history with reason-for-change capture, IQ/OQ/PQ validation documentation, ALCOA+ alignment, and advanced cryptographic signature schemes providing independently verifiable non-repudiation. Operationally, these functions are what make an electronic record legally and scientifically equivalent to — and in practice, often more defensible than — a signed paper original, by proving who did what, when, and that the record hasn't been altered since. This is essential in every laboratory operating under 21 CFR Part 11 or equivalent electronic-record regulations, where the evidentiary value of any digital result or document depends directly on the strength of the signature and audit-trail infrastructure behind it. Even outside strictly regulated contexts, many of these functions — version history, tamper-evident logging — are increasingly adopted as best practice for protecting research integrity and intellectual property, though the specific compliance weight of formal validation documentation and Part 11 signatures is concentrated in regulated industries.
- ✓21 CFR Part 11-compliant e-signatures
- ⚙Multi-level signature workflow (analyst/reviewer/approver)
- ✓Immutable audit trail (all modules)
- ✓Audit trail coverage of administrative/privileged system actions (user accounts, passwords, permissions, system files)
- ✓Audit trail logging of failed/unsuccessful action attempts (not just successful changes)
- ✓Prevention of e-signature copy/paste/reuse by another user
- ✕Tamper-attempt logging on the audit trail itself (recording attempts to modify/delete/disable the audit trail)
- ✕Audit trail processing failure detection and alerting (write errors, audit tool failure)
- ✓Prevention of electronic signature reuse or reassignment to a different user
- ⚙Revision history with reason-for-change capture
- ✓IQ/OQ/PQ validation documentation package
- ✓GAMP 5 risk-based validation alignment
- ✓ALCOA+ data integrity design principles
- ✓Tamper-evident logging
- ✓Time-stamped, non-repudiable action records
- ✓Validation support for SaaS/cloud deployment specifically
- ✕Autoverification system with rapid manual override/shutdown and revalidation capability
- ⚙eIDAS-compliant electronic signature (EU qualified trust service provider)
- ✓Advanced cryptographic electronic signatures (e.g., Ed25519 public-key) providing independently verifiable non-repudiation, distinct from credential re-entry signatures
- ½Dedicated traceability report module generating a complete linked chain-of-evidence history (materials, protocols, instruments, results) for a given experiment or sample
Security, Identity & Access Management
27 functions defined in this category. Vendor score: 15 / 27 (55.6%) — 4 Off-the-Shelf, 11 Configurable, 0 Extensible, 12 Not Supported.
This category governs who can access a laboratory system and what they're permitted to do once inside: authentication methods including multi-factor and single sign-on, role-based and granular permission structures, session management, encryption in transit and at rest, and administrative controls over account provisioning and deprovisioning. Its operational role is protecting both the confidentiality of laboratory data and the integrity of the record itself, since inadequate access controls can allow unauthorized viewing of sensitive results or, more seriously, unauthorized modification of data that later gets treated as authoritative. This matters for every laboratory handling any data with confidentiality or integrity requirements, which in practice describes essentially all laboratories, but the specific depth of controls needed scales with the sensitivity of the data involved and the regulatory framework a laboratory operates under — clinical and pharmaceutical environments in particular expect granular, auditable access control as a baseline expectation. As cyber threats targeting laboratory and healthcare data continue to grow, the sophistication of a platform's security architecture has become an increasingly decisive factor in platform evaluation, independent of any single regulatory mandate.
- ⚙Role-based access control (RBAC)
- ⚙SAML 2.0 / OAuth SSO
- ⚙LDAP/Active Directory integration
- ⚙Multi-factor authentication (MFA)
- ⚙AES-256 encryption at rest
- ⚙TLS 1.2+ encryption in transit
- ✕SOC 2 Type 2 attestation
- ✕ISO/IEC 27001 certification
- ✓Independent annual security audit
- ✓HIPAA Business Associate Agreement availability
- ⚙GDPR/CCPA compliance
- ✓Dedicated tenant / data isolation
- ✕CJIS Security Policy compliance (password standards, PIV/PKI authentication, encryption, cloud data residency within APB-member countries)
- ✕Time-of-day/network-address-based access restriction (chronometric and location-based access control)
- ⚙Configurable automatic account disablement after inactivity period
- ✕Configurable concurrent session control (allow/prevent multiple simultaneous logins per user)
- ⚙Configurable login banner/consent notification requiring acknowledgment before system use
- ⚙Configurable account lockout threshold (failed login attempt limit)
- ⚙Configurable session timeout with on-screen countdown warning before automatic logout
- ✓Vendor-enforced logical/physical access restriction to database storage infrastructure
- ✕Periodic account revalidation tagging and reminder scheduling (regulatory account certification)
- ✕Integration with physical security systems (badge access, building security) in addition to personnel directories
- ✕Authentication and role-based access control for embedded cryptographic modules
- ✕Explicit-permission activation control for connected cameras/microphones/collaborative devices with activation indicator
- ✕PII/PHI de-identification tools with segregation-of-duties enforcement (de-identified-data viewers cannot also hold re-identification access)
- ✕Consent management tools (recording and revoking individual consent for PII processing/storage)
- ✕Zero Trust security architecture applied to internal access controls
Accessibility, Localization & Standards Compliance
9 functions defined in this category. Vendor score: 7 / 9 (77.8%) — 3 Off-the-Shelf, 2 Configurable, 4 Extensible, 0 Not Supported.
This category covers how well a laboratory platform accommodates users with disabilities and operates across different languages, regions, and accessibility standards: WCAG conformance, screen-reader compatibility, keyboard navigation, browser-zoom support, multi-language interface localization, and regional date/number formatting. Its operational relevance centers on ensuring every staff member can actually use the system effectively regardless of disability or first language, and that an organization operating across multiple countries or linguistic groups isn't forced into a single-language, single-region interface that creates friction or errors for a meaningful portion of its workforce. This matters directly for any laboratory subject to accessibility legal requirements, such as public-sector or federally funded institutions in jurisdictions with specific accessibility mandates, and for any multinational or multilingual organization needing a genuinely localized interface rather than one only nominally translated. Laboratories operating with a single-language, single-region, non-disabled staff population will find these specific functions less immediately consequential, though genuine accessibility conformance benefits any organization by widening its potential hiring pool and reducing legal exposure.
- ✓Published VPAT / Accessibility Conformance Report
- ½WCAG 2.1 AA conformance level
- ½Section 508 conformance
- ½Keyboard-only navigation support
- ½Screen reader compatibility
- ⚙Multi-language / localization support
- ⚙Per-user selectable interface language (multi-language UI within a single deployment)
- ✓200% zoom / reflow support
- ✓Accessibility remediation roadmap published
Deployment Architecture & Scalability
9 functions defined in this category. Vendor score: 7.5 / 9 (83.3%) — 2 Off-the-Shelf, 5 Configurable, 1 Extensible, 1 Not Supported.
This category addresses the underlying technical architecture behind a laboratory platform's deployment: cloud versus on-premises hosting options, GxP-validated cloud environments, horizontal and vertical scalability, disaster recovery and backup architecture, uptime guarantees, and multi-tenant infrastructure design. Its operational relevance is largely infrastructural rather than directly user-facing, but it shapes practical questions that matter enormously over a platform's lifetime: how the system performs as sample volume and user count grow, what happens during a regional outage or disaster event, and whether hosting can meet the specific validation requirements a regulated laboratory's quality system demands. Cloud-hosted, GxP-validated deployment has become an increasingly common and often preferred option even in strictly regulated pharmaceutical and clinical environments, while some laboratories — particularly those with air-gapped security requirements or specific data-sovereignty obligations — still require or prefer on-premises, client-hosted deployment. Evaluating this category matters most during initial platform selection and any major growth or disaster-recovery-planning exercise, since architecture decisions made early are often costly to unwind later.
- ✓Cloud/SaaS hosting option
- ⚙On-premises/self-hosted option
- ⚙Air-gapped deployment support
- ½Independent business-rules/workflow tier (upgrade risk isolation)
- ⚙Low-code/no-code configuration (no scripting required)
- ⚙Disaster recovery & business continuity (defined RTO/RPO)
- ⚙Automated backup with verified restore
- ✕Configuration change management & promotion workflow (dev→test→production, audited)
- ✓Uptime monitoring & SLA
Clinical / LIS-Specific Capabilities
25 functions defined in this category. Vendor score: 12 / 25 (48.0%) — 0 Off-the-Shelf, 9 Configurable, 6 Extensible, 10 Not Supported.
This category addresses functionality specific to clinical laboratories operating as a Laboratory Information System, distinct from general-purpose LIMS functionality: CLIA complexity classification support, patient demographic and order management, HL7 interfacing with hospital information systems, specimen rejection criteria specific to clinical specimens, critical-value alerting, and integration with electronic health records. Its operational role is supporting the specific regulatory and clinical workflow requirements that distinguish patient testing from general industrial, environmental, or research laboratory work — requirements tied directly to patient safety, clinical decision-making, and healthcare billing and reporting ecosystems that don't have close equivalents outside the clinical context. This category is essential to hospital and reference clinical laboratories, where functions like critical-value alerting and EHR integration are not optional conveniences but core expectations tied directly to patient care timelines. General-purpose LIMS platforms serving industrial, environmental, food-safety, or research laboratories typically have little to no need for this category's functions, since their sample data never enters a clinical care pathway with the corresponding safety and regulatory obligations that clinical testing carries.
- ½HL7 v2 interface support
- ✕HL7 FHIR support
- ⚙STAT/routine priority workflow
- ⚙Patient demographic management
- ½Critical value alert routing
- ⚙Critical value read-back / acknowledgment documentation
- ✕Delta check (current-vs-prior result comparison, misidentification/anomaly flagging)
- ⚙Specimen rejection criteria & workflow (labeling, integrity, hemolysis/icterus/lipemia flagging)
- ½Cumulative patient report (historical results view across visits)
- ⚙Reference/send-out lab test tracking (name/address on report, result merge)
- ✕Antimicrobial susceptibility breakpoint management (CLSI/EUCAST/FDA)
- ⚙CLIA/CAP QC framework
- ½Physician ordering / results portal
- ✕Split specimen / MRO review routing (toxicology)
- ✕Electronic Lab Reporting (ELR) to public health authorities
- ½EMR/EHR system integration (published API, beyond HL7 messaging)
- ⚙Lab order management & test panel configuration (patient-centric)
- ✕Disease surveillance & epidemiological reporting (public health)
- ⚙Point-of-care testing (POCT) management module (centralized multi-site POCT oversight)
- ½Positive Patient Identification (PPID) at specimen collection
- ✕Microbiology expert rules / workup suggestion engine
- ✕CDC PHIN (Public Health Information Network) Messaging System interface
- ✕USCDI (United States Core Data for Interoperability) v2 standard support
- ⚙Configurable support for mandated code sets (ICD, HCPCS) in system nomenclature
- ✕Veterinary clinical terminology & data exchange standards support (SNOMED CT Veterinary Extension, VeNom Codes, ICAR/VICH, NAHLN HL7)
Industry-Specific Vertical Module Coverage
22 functions defined in this category. Vendor score: 13 / 22 (59.1%) — 0 Off-the-Shelf, 13 Configurable, 0 Extensible, 9 Not Supported.
This category captures purpose-built functionality tailored to a specific industry vertical beyond the general-purpose capabilities covered elsewhere in the matrix — cannabis and hemp potency testing, food and agricultural safety testing, environmental and water/wastewater compliance reporting, veterinary diagnostics, forensic toxicology, and other narrowly regulated or specialized testing domains, each often tied to specific state or federal reporting systems and industry-specific regulatory frameworks. Its operational relevance is inherently industry-specific rather than universal: a laboratory operating within one of these named verticals typically finds these purpose-built modules meaningfully reduce the configuration and compliance burden compared to adapting general-purpose functionality to fit specialized regulatory requirements, while a laboratory outside that vertical has no direct use for the corresponding module at all. This category is often where the difference between a truly general-purpose platform and one with deep, named vertical specialization becomes most visible during a platform evaluation, since a vendor's breadth of vertical coverage directly indicates how many distinct, specialized industries it has built dedicated, regulation-aware functionality for rather than relying on general configurability alone.
- ⚙Clinical Diagnostics
- ⚙Pharmaceutical & Biotech
- ⚙Environmental Testing
- ⚙Forensics / Medical Examiner
- ⚙Food & Beverage / Agriculture
- ⚙Cannabis Testing
- ⚙Academic & Core Research
- ✕Veterinary & Animal Health
- ⚙General Manufacturing QA/QC
- ⚙Used Oil / Industrial Fleet Testing
- ✕Toxicology / Workplace Testing
- ⚙Clinical Research / Bioanalytical Study Management (CRO, PK/ADA, drug development)
- ✕Blood Bank / Transfusion Services Management
- ✕Forensic DNA profile interpretation & CODIS-compatible workflow
- ✕Anatomic Pathology / Histology & Cytology Workflow
- ⚙Biobanking / Biorepository Sample Management (aliquot/derivative/pooled tracking, donor/study management)
- ✕Mining / Geochemical / Metallurgical Assay
- ✕Construction Materials / Geotechnical Testing
- ⚙Water & Wastewater Utilities
- ⚙Aerospace & Defense Materials Testing
- ✕Public Health Laboratories
- ✕Petroleum / Oil & Gas (Upstream & Midstream)
Support, Training & Professional Services
8 functions defined in this category. Vendor score: 5 / 8 (62.5%) — 5 Off-the-Shelf, 0 Configurable, 0 Extensible, 3 Not Supported.
This category covers the vendor-provided services surrounding the software itself: implementation and onboarding support, ongoing customer support and service-level commitments, training programs and documentation, professional services for custom configuration or integration work, and community or user-group resources. Its operational relevance, unlike most other categories, is less about a feature within the software and more about the vendor relationship supporting that software over the platform's operational lifetime — how quickly a support ticket gets resolved, how well new staff can be trained on the system, and whether a vendor's professional services team can deliver custom configuration work a laboratory's internal team cannot handle alone. This matters to every laboratory adopting or operating a platform, since even the most capable software still depends on effective onboarding, ongoing support, and staff training to be used correctly and to its full potential. The specific weight a laboratory places on this category often grows with platform complexity and the criticality of the systems involved, since a poorly supported implementation of an otherwise strong platform can still produce a disappointing overall experience.
- ✓Email/help desk support
- ✓Phone support
- ✕24/7 live support
- ✓Knowledge base / self-service documentation
- ✓Structured onboarding / implementation program
- ✕User community forums/groups for peer knowledge-sharing
- ✓Dedicated account management
- ✕Source code escrow availability
Vendor Added Categories
This chapter is where a vendor may define its own categories to highlight functions or features unique to its platform that are not covered by the standard 469-function LIMSpec Feature Matrix. Categories added here are numbered 29.1, 29.2, 29.3, and so on as they are added. Every function added under a vendor-added category adds to the overall Vendor LIMSpec Score exactly the same way a standard Feature Matrix function does, earning points by status (1 for Off-the-Shelf or Configurable, 0.5 for Extensible, 0 for Not Supported). No vendor-added categories have been defined yet.
Sources & Standards
The governing standards and frameworks referenced in constructing the Feature Matrix itself.
Each standard contributed specific functions or category structures to the matrix — for example, ASTM E1578 anchors the overall LIMS/LES/LIS/ELN/SDMS taxonomy and terminology; CLSI LIS08-A and the CAP Laboratory General Checklist anchor the clinical/LIS-specific category; ISA-88 and USP <1058> anchor the Laboratory Execution System category's batch/recipe governance functions; the OAIS Reference Model, PREMIS, and the FAIR Data Principles anchor the digital-preservation functions in the Scientific Data Management category; ISO 15489 anchors the records-management functions in Document Management; and ISO 31000, COSO ERM, and the OCEG GRC Capability Model anchor the governance-risk-compliance functions within Quality Management.
Supplementary Cross-Check Sources (Not Standards)
In addition to formal standards, the matrix was cross-checked against LIMSWiki's own LIMSpec (five separate section pages) and against an independently produced, AI-authored 190-feature ELN platform comparison (Benchling, SciNote, Dotmatics, Labguru, and Labfolder). Neither is a governing standard; both were used only to test the matrix's structural completeness against real-world, deeply researched functional taxonomies, in the same reference-only spirit as the vendor gap-check passes described above.
The Feature Matrix is maintained as a stable reference so that vendor profiles produced at different times remain comparable. Material additions to the matrix are expected to be infrequent, since the matrix has already been reviewed for structural completeness across every major architectural lineage in the laboratory informatics market.
Category Summary Table
All 28 standard categories and their function counts, totaling 469 functions. Any vendor-added categories from Chapter 29 are listed below the standard categories and included in the total.
| Category | # Functions |
|---|---|
| 1. Sample & Specimen Management | 21 |
| 2. Case & Project Management | 19 |
| 3. Test, Method, Specification & Limits Management | 16 |
| 4. Laboratory Execution System (LES) | 15 |
| 5. Electronic Lab Notebook (ELN) Core | 26 |
| 6. Scientific Data Management (SDMS) | 18 |
| 7. Stability, Formulation & Batch Management | 10 |
| 8. Molecular Biology / Life Sciences Tools | 27 |
| 9. Instrument & Equipment Integration | 25 |
| 10. Robotics, Automation & IoT | 10 |
| 11. Enterprise System Integration (ERP / MES / CDS / API) | 14 |
| 12. AI, Machine Learning & Predictive Analytics | 24 |
| 13. Mobile, Remote Access & Multi-Site Operation | 9 |
| 14. Inventory, Reagent & Asset Management | 17 |
| 15. Document Management & Control | 16 |
| 16. Learning & Competency Management (LMS) | 10 |
| 17. Client / Patient / Physician Portal & Collaboration | 8 |
| 18. Billing, Customer & Project Administration | 8 |
| 19. Business Intelligence, Dashboards & Reporting | 27 |
| 20. Quality Management, CAPA & Investigation (OOS/OOT) | 23 |
| 21. Statistical Process / Quality Control (SPC/SQC) | 6 |
| 22. Electronic Signatures, Audit Trail & Validation | 20 |
| 23. Security, Identity & Access Management | 27 |
| 24. Accessibility, Localization & Standards Compliance | 9 |
| 25. Deployment Architecture & Scalability | 9 |
| 26. Clinical / LIS-Specific Capabilities | 25 |
| 27. Industry-Specific Vertical Module Coverage | 22 |
| 28. Support, Training & Professional Services | 8 |
| TOTAL | 469 |
Complete LIMSpec Methodology Source List
Appendix A lists the standards most directly cited in this document's own preface narrative. The list below is the fuller source list LIMSWiki's own LIMSpec methodology draws from — over 130 regulations, standards, accreditation requirements, and guidance documents that collectively shaped the Feature Matrix, organized by governing body or domain. This list is reproduced here because the preface's narrower citation set understated how broad LIMSWiki's actual sourcing is; it should be read as a supplement to, not a replacement for, Appendix A.
Each function in the Feature Matrix traces back to at least one item below. Where a source is proprietary (for example, certain accreditation body checklists), LIMSWiki notes it was either purchased for review or researched via supporting public documentation. Some further sources — such as AOAC International's Official Methods of Analysis, and the U.S. Food Emergency Response Network / Laboratory Response Network's internal procedures — are excluded entirely because they are either prohibitively proprietary or not published for public reference at all.
U.S. Federal Regulations (CFR)
| Citation | Governing Body / Subject |
|---|---|
| 5 CFR Part 930.301 | Office of Personnel Management — information systems security awareness training |
| 7 CFR Part 91 | USDA Agricultural Marketing Service — commodity laboratory testing programs |
| 7 CFR Part 331 | USDA APHIS — possession, use, and transfer of select agents and toxins |
| 9 CFR Part 2 | USDA APHIS — animal welfare regulations |
| 9 CFR Part 121 | USDA APHIS — select agents and toxins (viruses, serums, organisms) |
| 10 CFR Part 20 | Nuclear Regulatory Commission — protection against radiation |
| 10 CFR Part 30 | Nuclear Regulatory Commission — licensing of byproduct material |
| 21 CFR Parts 1, 7, 11, 58 | FDA — general enforcement, electronic records/signatures, Good Laboratory Practice |
| 21 CFR Parts 106, 110, 111, 112, 114, 117, 120, 123, 129 | FDA — food manufacturing, dietary supplements, produce safety, HACCP, seafood, bottled water |
| 21 CFR Parts 211, 212, 225, 226 | FDA — cGMP for finished pharmaceuticals, PET drugs, medicated feeds/articles |
| 21 CFR Part 312 | FDA — Investigational New Drug Application |
| 21 CFR Part 507 | FDA — cGMP/HACCP for animal food |
| 21 CFR Part 606 | FDA — cGMP for blood and blood components |
| 21 CFR Parts 810, 812, 820 | FDA — medical device recall authority, investigational device exemptions, Quality System Regulation |
| 29 CFR 1910.120, .134, .1030, .1096, .1200, .1450 | OSHA — hazardous waste, respiratory protection, bloodborne pathogens, ionizing radiation, hazard communication, lab chemical exposure |
| 40 CFR Part 3 | EPA — cross-media electronic reporting |
| 40 CFR Parts 60, 62, 63 | EPA — air program emission standards |
| 40 CFR Part 141 | EPA — National Primary Drinking Water Regulations |
| 40 CFR Parts 262, 370, 372 | EPA — hazardous waste generator standards, community right-to-know reporting |
| 40 CFR Parts 704, 717, 720 | EPA — Toxic Substances Control Act reporting/recordkeeping |
| 42 CFR Part 73 | Public Health Service — select agents and toxins |
| 42 CFR Part 93 | Public Health Service — research misconduct policy |
| 42 CFR Part 493 | CMS — CLIA laboratory requirements |
| 45 CFR Parts 160, 162, 164 | HHS — HIPAA administrative, security, and privacy requirements |
| 45 CFR Part 170 | ONC — health IT certification criteria |
| 61 FR 38806 | USDA FSIS — Pathogen Reduction/HACCP Systems |
Accreditation Bodies & Laboratory-Specific Programs
| Source | Body |
|---|---|
| A2LA C211 (ISO/IEC 17025 + Veterinary Laboratory Accreditation) | American Association for Laboratory Accreditation |
| A2LA C223 (Forensic Examination Accreditation — Testing) | American Association for Laboratory Accreditation |
| AAFCO QA/QC Guidelines for Feed Laboratories | Association of American Feed Control Officials |
| AAVLD Requirements for an AVMDL | American Association of Veterinary Laboratory Diagnosticians |
| ABFT Accreditation Manual | American Board of Forensic Toxicology |
| ACMG Technical Standards for Clinical Genetics Laboratories | American College of Medical Genetics and Genomics |
| AIHA-LAP Policies | American Industrial Hygiene Association Laboratory Accreditation Programs |
| APHL LIS Project Management Guidebook | Association of Public Health Laboratories |
| ASCLD/LAB Supplemental Requirements for Forensic Science Testing Laboratories | American Society of Crime Laboratory Directors / Laboratory Accreditation Board (proxy for ANAB, whose current forensic requirements are not public) |
| CAP Laboratory Accreditation Manual | College of American Pathologists |
| NYSDOH CLEP Clinical Laboratory Standards of Practice | New York State Department of Health, Clinical Laboratory Evaluation Program |
| NYSDOH ELAP Medical Marijuana Microbiology Guidance | New York State Department of Health, Environmental Laboratory Approval Program |
| TNI EL-V1-2016 | The NELAC Institute — environmental laboratory management and technical requirements |
| USDA Laboratory Approval Service (LAS/LAP) Policies | U.S. Department of Agriculture |
| USDA Pesticide Data Program (administrative procedures, sampling, data/instrumentation, sample processing) | U.S. Department of Agriculture |
| USDA Hemp Production Program Laboratory Testing Guidelines | U.S. Department of Agriculture |
ASTM, ISO, and Clinical/Technical Standards
| Standard | Title / Subject |
|---|---|
| ASTM E1188-11(2017) | Collection and Preservation of Information and Physical Items by a Technical Investigator |
| ASTM E1459-13(2018) | Physical Evidence Labeling and Related Documentation |
| ASTM E1492-11(2017) | Receiving, Documenting, Storing, and Retrieving Evidence in a Forensic Science Laboratory |
| ASTM E1578-18 | Standard Guide for Laboratory Informatics — the core standard LIMSpec is rooted in |
| ISO 15189:2012 | Medical laboratories — Requirements for quality and competence |
| ISO/IEC 17025:2017 | General requirements for the competence of testing and calibration laboratories |
| ISO/TS 22002-1:2009, -4:2013, -6:2016 | Prerequisite programmes on food safety — manufacturing, packaging, feed/animal food |
| CLSI AUTO15, AUTO16, QMS22 | Clinical and Laboratory Standards Institute — automation/informatics and quality management |
| ISO/IEC/IEEE 29148:2018 | Systems and software engineering — requirements engineering (underlies LIMSpec's own requirement-writing methodology) |
Food Safety & Agricultural Standards
| Source | Body |
|---|---|
| BRC Global Standard for Food Safety, Issue 8 | BRC Global Standards |
| Codex Alimentarius CXC 1-1969, CXS 193-1995, CXS 234-1999 | FAO/WHO Codex Alimentarius — hygiene, contaminants, methods of analysis |
| FDA HACCP Guidelines | U.S. Food and Drug Administration |
| GFSI Benchmarking Requirements v2020.1 | Global Food Safety Initiative |
| IFS Food 7 / IFS PACsecure 2 | International Featured Standards |
| Safe Food for Canadians Regulations SOR/2018-108 | Government of Canada |
| SQF Food Safety Code, Ninth Edition (Food Manufacturing, Pet Food, Food Packaging) | FMI / SQF Institute |
| PFP Human and Animal Food Testing Laboratories Best Practices Manual | Partnership for Food Protection |
Environmental, Pharmaceutical & International Guidance
| Source | Body |
|---|---|
| EPA 815-R-05-004 (Drinking Water Lab Certification Manual) | U.S. Environmental Protection Agency |
| EPA ERLN Laboratory Requirements v1.6 | EPA Environmental Response Laboratory Network |
| EPA Metadata Technical Specification | U.S. Environmental Protection Agency |
| EPA QA/G-5 (Quality Assurance Project Plans) | U.S. Environmental Protection Agency |
| EPA SEDD Specification & Data Element Dictionary v5.2 | U.S. Environmental Protection Agency |
| FDA ORA DX Program | U.S. Food and Drug Administration |
| EMA Guidance on GMP/GDP | European Medicines Agency |
| E.U. Annex 11; Commission Directive 2003/94/EC; Reg. 852/2004; Reg. 2073/2005 | European Union / European Commission |
| ICH GCP | International Council for Harmonisation — Good Clinical Practice |
| OECD GLP Principles | Organisation for Economic Co-operation and Development |
| WHO TRS #961 Annex 13; #986 Annex 2; #996 Annex 5 | World Health Organization — laboratory information files, GMP principles, data/record management |
| DoD General Data Validation Guidelines | U.S. Department of Defense |
Security, Public Health & Specialty Domain Standards
| Source | Body |
|---|---|
| CJIS Security Policy | FBI Criminal Justice Information Services |
| NIST SP 800-53, Rev. 5 | National Institute of Standards and Technology |
| CDC Biosafety in Microbiological and Biomedical Laboratories (BMBL) | U.S. Centers for Disease Control and Prevention |
| CDC PHIN Messaging System | U.S. Centers for Disease Control and Prevention |
| ONC United States Core Data for Interoperability (USCDI) | Office of the National Coordinator for Health IT |
| OSHA 1910.1020, 1910.1200, 1910.1450 | Occupational Safety and Health Administration |
| WADA International Standard for Laboratories (ISL) | World Anti-Doping Agency |
| WADA International Standard for the Protection of Privacy and Personal Information (ISPPPI) | World Anti-Doping Agency |
| ICAR 15 Data Exchange | International Committee for Animal Recording |
| VICH GL53 (Electronic Exchange of Documents) | Veterinary International Conference on Harmonization |
| NAHLN HL7 Messaging Quick User Guide; NAHLN IT System | National Animal Health Laboratory Network |
| VeNom Coding Group terminology | Veterinary Nomenclature (VeNom Coding Group) |
| VTSL terminology | Veterinary Terminology Services Laboratory, Virginia-Maryland College of Veterinary Medicine |
This source list is reproduced from LIMSWiki's own "LII:LIMSpec/Introduction and methodology" page, which documents that its fourth revision (December 2022) draws on more than 130 resources. LIMSWiki notes this remains a work in progress, with additional sources incorporated as public and private comment identifies gaps. This document defers entirely to LIMSWiki's own account of its sourcing rather than independently verifying each citation.
LIMSpec Version History
This appendix records every versioned revision to the LIMSpec master template since the current major edition (2026R1) was established, per the versioning scheme described in the Preface. Each entry reflects a confirmed version bump, not every individual edit made along the way — some sessions accumulate several changes before a version number is assigned. The 2026R1 baseline itself introduced the major structural upgrade from a flat checklist to the current per-function rationale text, Vendor Profile table, and live scoring architecture.
When Does the Version Increment to a New Major Edition?
Every revision listed below is a decimal increment — 2026R1.1, 2026R1.2, and so on, with no cap — because each one extended or improved the existing document without changing what the document fundamentally is. The dividing line for moving to a new major edition (2026R2, or 2027R1 at a new calendar year) is whether a change alters what the document is, rather than just what it does. A useful test: could a vendor profile filled out under the current major edition still open correctly, with nothing lost, under the proposed new version? If yes, it is decimal territory. If no, it warrants a major-edition bump.
Concretely, a major-edition bump is warranted when:
- The Feature Matrix itself changes — functions or categories are added, removed, or renumbered, since the 469-functions-across-28-categories structure is the fixed spine every score, table, and export depends on.
- A new calendar year or a planned major edition arrives, per the versioning scheme's own stated fallback.
- The underlying data format changes in a way that makes older filled-in profiles genuinely incompatible without a migration step, as opposed to remaining directly openable in the new version.
By contrast, additions as substantial as Chapter 29 (Vendor Added Categories) or replacing the rich-text editing engine both represented real engineering effort and real behavior change, yet stayed decimal increments — because a profile filled out on an earlier decimal version still opens correctly on a later one, with nothing lost. Reversibility and continuity of existing vendor data, not the size or effort of a change, is what determines whether a revision is decimal or major.
| Version | Summary of Changes |
|---|---|
| 2026R1.1 | Removed the "No Vendor Sponsorship or Review" subsection from Independence & Authorship. |
| 2026R1.2 | Renamed the Feature Matrix lightbox's "Vendor Approach" tab to "Vendor Information"; added an initial "Download Word Copy" button. |
| 2026R1.3 | Replaced the Word export with a genuine client-side-generated .docx (real OOXML, hand-built ZIP and CRC32, no external libraries), including real Word heading styles, bookmarks, and a working, pre-populated table of contents that renders correctly when opened in both Microsoft Word and Google Docs. |
| 2026R1.4 | Restructured the per-category Word export from a single wide table into 469 individual stacked tables, one per function, with Function / Functional Requirement / Vendor-Product Info / Status rows; Sources dropped from the export. |
| 2026R1.5 | Changed each per-function Word table from a two-column (label | value) layout to a single column, with each row's label and value combined on one line. |
| 2026R1.6 | Fixed a bug where literal HTML entities in the source data (for example, "'" instead of an apostrophe) displayed as visible text in the Word export; set the Function row to 20pt bold in the Word export. |
| 2026R1.7 | Added keep-together page-break behavior to each per-function Word table, so it stays on one page whenever it fits and only splits if it is genuinely longer than a full page. |
| 2026R1.8 | Replaced the cover banner's static "Document Type" field with a live "Vendor LIMSpec Score" counter; simplified the scoring model from four statuses to two (Documented / Not Supported only, removing Partially Documented and Not Publicly Documented) across the scoring rubric, the Feature Matrix, and the Word export; fixed a pre-existing bug in the Word export's version-number lookup. |
| 2026R1.9 | Added "The LIMSpec Is a LabLynx Creation" subsection to Independence & Authorship, disclosing LabLynx, Inc.'s role in creating LIMSpec and LiMSwiki.org as a joint community effort, and affirming LabLynx's own vendor profile is held to the same evidentiary standard as every other vendor. |
| 2026R1.10 | Renamed "Company Profile" to "Vendor Profile" everywhere user-visible; added a dynamic banner title that appends the vendor's Legal Name onto "LIMSpec" once entered and saved. |
| 2026R1.11 | Extended the dynamic banner title to also update the dark navy cover-page banner, so both the sidebar and cover page stay in sync. |
| 2026R1.12 | Changed the cover banner's label text to bright white for readability; added an entirely new Chapter 29, "Vendor Added Categories," letting a vendor define its own custom categories and function points (autonumbered 29.1, 29.2, 29.3…) that count toward the overall Vendor LIMSpec Score the same way standard functions do, with the Category Summary Table and Word export updated to include them automatically. |
| 2026R1.13 | Added a roughly 50-word description field to vendor-added categories; renamed "Rename Category" to "Edit Category" to reflect that it now edits both the name and description together. |
| 2026R1.14 | Made the "Download Updated Copy" (HTML) button use the same vendor-based root filename convention as the Word export, so both downloaded files share a matching name. |
| 2026R1.15 | Fixed a bug where both download buttons silently did nothing when the file was opened from the local filesystem (a file:// URL) — a Chrome/Chromium security restriction on blob-URL downloads from local pages, not a logic error — by falling back to a data URI in that specific case. |
| 2026R1.16 | Fixed a bug where category score lines (for example, "Vendor score: 9 / 21") only computed when a function was edited interactively through the modal, so a file opened with scoring data already present (such as a completed vendor profile) showed no score line until something was edited; added an initialization-time pass that recomputes every category's score display on load, regardless of how the data got there. Added this appendix, Appendix D, recording the version history from 2026R1.1 onward; keeping it current is now standing practice for every future version bump. |
| 2026R1.17 | Replaced the raw contenteditable/execCommand rich-text editing (Vendor Information field, Vendor Profile fields, Chapter 29 vendor-added functions) with Quill, a self-hosted, fully offline-embedded WYSIWYG editor (no CDN dependency, no API key) — same formatting capabilities (bold, italic, lists, links, and image upload where previously available) with a more polished editing experience. As part of this change, the Vendor Profile table moved from bulk "edit all 15 fields at once" to one-field-at-a-time modal editing, matching how the Vendor Information and Chapter 29 editors already worked, for a consistent editing pattern throughout the document. Added a new "When Does the Version Increment to a New Major Edition?" subsection to this appendix, explaining the R1-to-R2 threshold. |
| 2026R1.18 | Added drag-to-resize and click-to-align (left/center/right, with text wrap) for images within Quill, via the self-hosted quill-blot-formatter2 module (no CDN dependency) registered across all three rich-text editing surfaces. Clicking an image now shows four corner resize handles plus a small alignment/link/alt-text toolbar. Added supporting CSS so a resized or aligned image continues to display correctly with its float and margin outside the live editor as well (e.g. the read-only Vendor Information panel), not just while editing. No changes were needed to the Word export's existing image-handling logic, since a resized/aligned image is still a plain <img> tag (optionally wrapped in an alignment <span>), which the export's existing recursive HTML parser already finds correctly regardless of wrapping. |
| 2026R1.19 | Moved "Category Summary Table" out of the Reference section's own numbering (previously "30.") and renumbered it as Appendix B, sitting between Appendix A and the document's former Appendix C; deleted the former Appendix B ("Vendor Cited Sources"), which had defined the sourcing-requirement methodology (Documented only when directly confirmed in a vendor's own materials, everything else Not Supported) for completed vendor profiles. Fixed a resulting dangling cross-reference in Independence & Authorship that had cited "(Appendix B)" for vendor-sourcing traceability; the underlying claim still holds via each function's own Sources field, so the sentence was reworded rather than left pointing at deleted content. Appendix C and Appendix D keep their existing letters and content unchanged. |
| 2026R1.20 | Simplified the sidebar TOC label for Chapter 1 from "Chapter 1: Vendor Profile" to just "Vendor Profile" (the in-page chapter header and Word export heading still say "Chapter 1"). Added a new "Laboratory Profile" section to the Introduction group, positioned before Vendor Profile — a 15-field editable table (organization identity, contact information, and general software needs: staff/user count, sample volume, current systems, deployment preference, regulatory requirements, functional priorities, integration needs, timeline/budget) for the laboratory or organization evaluating vendors using this document, using the same per-row Quill-editing pattern as Vendor Profile. Included in the Word export, positioned immediately before Chapter 1, but only when at least one field has been filled in — left blank, it is omitted entirely rather than exporting a section of placeholder rows. |
| 2026R1.21 | Added a new chapter, "The LIMSpec and How to Use It," as the first item in the Introduction group, ahead of Open Access License — a practical walkthrough covering what the LIMSpec is (with benefits framed for laboratories, vendors, and both together), how a laboratory reads a completed profile and fills in its own Laboratory Profile, and how a vendor fills in its Vendor Profile, answers functions with proper evidentiary discipline, and uses Chapter 29 for genuine differentiation. Illustrated with 13 real screenshots of the live application itself (captured via a headless Chromium instance already available in the working environment, not hand-drawn illustrations), covering every editing surface: the function detail modal in both tabs, the Quill-based edit view, Chapter 29's add-category and add-function dialogs, the Vendor Profile table and field-edit modal, the dynamically-updated title banner with live score, and the download buttons. Adds roughly 3.5MB to the file (screenshots only); the new chapter is correctly excluded from the Word export, which continues to cover only Laboratory Profile (if filled in), Chapter 1, and the Feature Matrix chapters. |
| 2026R1.22 | Added a new "Upgrade LIMSpec" button to the sidebar. Clicking it opens a modal showing the current file's version alongside the latest version, automatically fetched from the canonical published template at media.limswiki.org/books/51; an "Upgrade" button then migrates every function status/write-up/sources, Vendor Profile field, and Laboratory Profile field into a fresh copy of that latest template by matching on function name or field label, carries Chapter 29 vendor-added categories over unchanged (they are not part of the fixed matrix), and downloads the result as a new file, leaving the current file untouched. If the automatic fetch fails for any reason (a cross-origin restriction on the hosting server, or a network issue), the same modal falls back to a manual file picker with a direct link to the source, using identical migration logic either way. Anything that cannot be matched (for example, a renamed function) is reported in an on-screen migration summary rather than silently dropped. Fixed a bug found during testing where the migration code's own generated string contained a literal </script> sequence, which would have prematurely closed the surrounding script tag in any browser. |
| 2026R1.23 | Reworked the Upgrade feature (renamed "Upgrade LIMSpec" to "Upgrade My LIMSpec") to reverse the migration direction and remove the network fetch entirely: the template currently open is now treated as the upgrade target on the assumption the user has already navigated to the latest published version at media.limswiki.org/books/51, and the modal simply asks for an older, filled-out LIMSpec file via a local file picker as the migration source — sidestepping the cross-origin question from 2026R1.22 altogether, since nothing is fetched from anywhere. Migrating now also updates this page's own live data immediately (score banner, Vendor Profile table, title banner all refresh in place), not just the downloaded copy. Moved the button out of the sidebar and into the dark navy cover banner, positioned immediately to the right of the Version field, styled with the site's existing orange accent color for visibility against that background. |
| 2026R1.24 | Widened the Feature Matrix function detail lightbox by 50% (max-width 760px → 1140px). The lightbox's internal content (icon, tabs, text panel) keeps its own natural width rather than stretching to fill the added space. |
| 2026R1.25 | Fixed a bug found immediately after 2026R1.24: the lightbox's outer box had genuinely widened to 1140px, but a global p { max-width: 860px; } rule (written for body prose elsewhere in the document) was also silently capping the paragraph text inside the modal, so the visible content barely changed and left a large empty gap on the right. Added a .mf-panel p { max-width: none; } override so the text now fills the full widened container. Verified at both a typical laptop width (1280px, text now spans the full box with no dead space) and a narrower window (900px, the modal still shrinks responsively rather than overflowing). |
| 2026R1.26 | Fixed a second, more subtle download bug: the file:// fallback for both download buttons used FileReader.readAsDataURL(), which is asynchronous, meaning the actual download-triggering click happened inside an async callback after the original click had already completed - a gap in which Chrome can stop treating the action as user-initiated and silently block it with no visible feedback. Rewrote the fallback to be fully synchronous (built via btoa directly, no FileReader at all), so the click and the download now happen in the same call stack every time. Reworked "Upgrade My LIMSpec" substantially, introducing an explicit distinction between the blank LIMSpec Master Template and a filled-out LIMSpec Vendor Profile built from it: the title now reads "LIMSpec - Master Template" until a Vendor / Product name is filled in, at which point it switches to "LIMSpec - {name}" as before; the Upgrade button itself is now only shown while the page is the blank Master Template, disappearing once a vendor name is present, since only the Master Template is a valid upgrade target. The uploaded file is now validated immediately upon selection (checked for a version number and the expected Feature Matrix / Vendor Profile data blocks), with a specific inline error shown right away rather than only failing later. Migration no longer touches this page's own live data at all - it works entirely on cloned copies, so the open Master Template is never altered, confirmed by snapshotting its data before and after a migration and verifying an exact match. The modal now has two views: a setup view (file picker) and, after clicking Upgrade, a result view showing the migration summary plus a real, pre-built "Download Upgraded File" link the user clicks themselves, rather than an automatically triggered download - both because it is less ambiguous about what just happened, and because a genuine physical click on a real link sidesteps the async-download-blocking risk entirely. Verified with a real physical mouse click (not a simulated one) in actual Chrome. |
| 2026R1.27 | Added a new "Keeping Your LIMSpec Profile Current" section to the end of "The LIMSpec and How to Use It" chapter, covering the Upgrade My LIMSpec feature: why it exists (the template evolves; older profiles do not auto-update), the Master Template vs. Vendor Profile distinction and why the button only appears on the blank template, the actual setup-then-upgrade flow, and what happens when a function cannot be matched during migration (reported plainly, not silently dropped). Illustrated with two real screenshots of the live application (the cover banner showing the button only on the blank Master Template, and the Upgrade modal’s setup view). |
| 2026R1.28 | Added a light-gray banner above the dark-navy cover, containing the LiMSwiki logo embedded as inline SVG (fully self-contained, no external image dependency). Removed the cover banner’s "LiMSwiki.org · Version X" eyebrow line entirely and reduced the cover’s top padding (80px → 40px) to close the resulting excess space above the title — the version string now appears in 5 places rather than 6, since this eyebrow was previously one of them. Moved the matrix search box out of the sidebar and into the new gray banner, positioned opposite the logo; the same element IDs were kept throughout, so no JavaScript changes were needed and the existing search, results dropdown, and Ctrl/Cmd+K shortcut all continued working immediately in the new location. Made the search box’s orange border permanent rather than focus-only, and corrected its vertical alignment to be centered with the logo — measured a real 10.8px offset first, then found that the obvious fix (margin-top) only corrected half of it because it also grew the flex container and re-centered the logo along with it; switched to a position: relative; top offset instead, which does not affect layout sizing, confirmed down to a 0.2px difference. All changes verified visually via real Chrome screenshots, including measuring exact element positions, before being finalized. |
| 2026R1.29 | Added a "find in page" widget to the matrix search: typing a query now highlights every occurrence across the visible page (category text and function names, the same content the existing results dropdown already searches) and shows a small counter with Previous/Next buttons to step through matches one at a time, similar to a browser’s built-in Find bar. The widget and the pre-existing results dropdown are mutually exclusive (the widget takes over once there are highlight matches) after an initial version briefly rendered both stacked on top of each other in the same space, caught via a real screenshot rather than the automated tests alone. Closing the widget fully un-wraps every highlight and restores the original text nodes, verified byte-for-byte identical before and after. Fixed a second issue found immediately after: the widget was originally positioned relative to the search box in the gray banner, which is not fixed on scroll, so navigating to a match anywhere past the first screen left the widget over 20,000px off-screen and completely invisible — measured directly rather than assumed. Switched it to position: fixed, pinned to the top-right of the viewport, confirmed to remain visible and correctly positioned at every step while navigating through matches far down the document. |
| 2026R1.30 | Removed the "LiMSwiki Laboratory Informatics Vendor Profile" line from the dark-navy cover banner (left unchanged everywhere else it appears - sidebar, page title, meta description, license text, Preface). Replaced the cover subtitle text with a description centered on LIMSpec’s actual purpose — a shared, standards-referenced vocabulary letting a laboratory evaluate any vendor on the facts and a vendor describe its own product completely and accurately — sized to within 20 characters of the original (320 vs. 340) so the banner layout is unaffected, confirmed visually. |
| 2026R1.31 | Locked the gray logo banner in place: it is now position: fixed at the top of the viewport (spanning from the sidebar’s right edge to the viewport edge) so it, and the search box within it, remain visible while scrolling. Added compensating top padding to the main content area matching the banner’s exact measured height so nothing hides underneath it on load. Made the logo a clickable link that smooth-scrolls back to the top of the page. Simplified the find-in-page widget back to being anchored under the search box (position: absolute rather than position: fixed), since the search box is now always visible and no longer needs the viewport-pinned workaround from 2026R1.29. Replaced the LiMSwiki logo in the gray banner with a new supplied LIMSpec logo (flask/checkmark mark, wordmark, and "Standardized Requirements for Laboratory Software" tagline), embedded as base64 PNG; sized taller (58px, up from 42px) than the previous logo to keep the tagline legible, verified at 2x resolution. Caught and fixed a real bug during this change: the taller logo grew the fixed banner’s height from ~88.6px to 95px, but the compensating top-padding added earlier in this version was still hardcoded to the old value, leaving a 6px overlap; corrected to match exactly, confirmed by re-measuring both values directly rather than assuming. In the sidebar, replaced "LiMSwiki.org" with "LIMSpec.com" linked to https://limspec.com (opens in a new tab), and removed the "LiMSwiki Laboratory Informatics Vendor Profile · 469 Functions · 28 Categories" description line beneath the title entirely, along with its now-unused CSS rule. |
| 2026R1.32 | Increased the logo size in the gray banner (68px, up from 58px), remeasuring the banner’s new height (105px, up from 95px) and updating the main content area’s compensating top padding to match exactly, confirmed with no gap or overlap; the logo/search box vertical alignment was also re-verified and needed no adjustment. Renamed the sidebar navigation section "The Feature Matrix" to "Vendor/Product LIMSpec" (the group of 28 category links). Checked for other references to this section specifically and found none needing updates — "Feature Matrix" elsewhere in the document (methodology, appendices, license text) is the established technical term for the 469-function/28-category structure itself, not a reference to this sidebar grouping, and was left unchanged. |
| 2026R1.33 | Added a new "Profiles" section to the sidebar navigation, positioned between the Introduction group and the Vendor/Product LIMSpec group. Moved the "Laboratory Profile" and "Vendor Profile" links out of their previous locations (Introduction and Vendor/Product LIMSpec respectively) into this new grouping. No change to the underlying chapter content or physical placement in the document body was required, since both chapters already sat consecutively immediately before "1. Sample & Specimen Management." |
| 2026R1.34 | Added a new "Vendor/Product LIMSpec Score" subsection to the Vendor Profile chapter, positioned between the chapter intro and the editable Vendor Profile table. Explains how the score is computed (count of functions marked Documented, summed across all 28 Feature Matrix categories plus any Chapter 29 Vendor Added Categories, with every function weighted equally) and displays the live score in bold. Wired into the existing updateVendorScore() function so this new display updates in lockstep with the pre-existing cover-banner score whenever a function's status changes, verified via a scripted UI test that marked a function Documented and confirmed both displays updated to the same value. |
| 2026R1.35 | Replaced the plain-text Vendor/Product LIMSpec Score subsection with a live-updating visual badge (vendor icon, vendor/product name, "LIMSpec Score: {value}", and version), embedding the actual LIMSpec flask-and-checkmark icon rather than the generic in-document sprite. The same badge now also appears on the dark cover banner, taking the place of the previous separate "Vendor LIMSpec Score" and "Version" text fields; both badge instances read from and update via the existing vendorScoreValue, coverVersionValue, and updateBrandTitle()/updateVendorScore() logic, so no new update wiring was needed and no 6th version-string location was introduced. Removed the Laboratory Profile chapter entirely, including its sidebar nav link, editable table, "Filling In the Laboratory Profile" tutorial subsection and screenshot, and all associated JavaScript (render/edit/save functions, its JSON data block, and every reference in the version-upgrade migration logic and the Word-export logic); the Profiles sidebar group now contains only Vendor Profile. Verified via a full scripted pass confirming zero console errors, correct badge behavior on both the blank Master Template and a filled-in profile, and no orphaned Laboratory Profile references anywhere in the page. |
| 2026R1.36 | Moved the "Vendor Profile" sidebar link out of the "Profiles" group (now empty and removed) into the "Vendor/Product LIMSpec" group, positioned before "1. Sample & Specimen Management" — matching the chapter's existing physical position in the document body, which was already immediately before Category 1 and did not need to move. Renamed the "Download Updated Copy" sidebar button to "Download Vendor LIMSpec" (HTML export); the Word export button and its "Download Word Copy" label are unchanged. Both changes verified with a scripted UI pass showing zero console errors and the correct nav order and button label. |
| 2026R1.37 | Removed the large circular icon illustration from the top of the function detail modal (below the header, above the Functional Requirement / Vendor Information tabs), reclaiming that vertical space for the description and edit content below; the small icon next to the function title in the modal header is unchanged and still updates per-category as before. Added a live score suffix to the "Vendor Profile" sidebar link, so it now reads "Vendor Profile - {score}" (or "Vendor Profile - No Score" when blank), wired into the existing updateVendorScore() function alongside the cover-banner and chapter-badge score displays so it updates in lockstep with no separate event handling required. Verified via a scripted UI pass confirming zero console errors, correct modal layout with the illustration removed, and the nav label updating correctly after marking a function Documented. |
| 2026R1.38 | Standardized the downloaded-file naming convention across all three export paths to limspec-{version}-{vendor} (lowercase prefix, current document version, then the sanitized Vendor/Product name or "vendor-profile" when blank): the "Download Vendor LIMSpec" HTML button, the "Download Word Copy" button, and the "Upgrade My LIMSpec" migration output (which now appends "-upgraded" instead of the previous "-upgraded-to-{version}" suffix, since the version is already present in the new prefix). Previously each of the three used a different, inconsistent "LiMSpec-{vendor}" pattern with no version in the filename. Verified via a scripted pass exercising all three download paths with both a blank and a filled-in Vendor/Product name, confirming the expected filenames (e.g. limspec-2026R1.38-vendor-profile.html, limspec-2026R1.38-Acme_LabSuite.docx) and zero console errors. |
| 2026R1.39 | Refreshed all 13 screenshots embedded in "The LIMSpec and How to Use It" tutorial chapter, which had gone stale across several versions of visual redesign (old sidebar branding, no fixed logo banner, the pre-badge cover layout, the now-removed modal illustration, the old "Download Updated Copy" button label, and the old flat Vendor/Product LIMSpec Score text). Recaptured each via a scripted Puppeteer pass exercising every subject fresh against the current template: page overview, a Feature Matrix category list, both tabs of the function detail modal, the edit view, the Vendor Profile chapter and cover banner with a sample vendor name and live score, Chapter 29's empty state plus its Add Category and Add Function dialogs and populated result, the sidebar download buttons with an unsaved-edits indicator, and the Upgrade My LIMSpec button and modal on a blank Master Template. Alt text and captions were left untouched; only the image bytes were swapped, each verified to match its existing caption. Corrected one line of prose describing the Upgrade button's position ("next to the version number" → "next to the LIMSpec Score badge") to match the current cover-banner layout. Along the way, found and fixed a genuine Puppeteer bug in the capture tooling itself: page.screenshot({clip}) resolves clip coordinates against a synthetic full-page render rather than the current scrolled viewport, silently breaking capture of any position:fixed overlay (such as these modals) once the page is scrolled — switched to plain viewport screenshots and elementHandle.screenshot() instead, which capture correctly regardless of scroll position. Verified via a final scripted pass confirming all 13 images load, zero console errors, and the edit/score workflow still functions correctly. |
| 2026R1.40 | Expanded the WYSIWYG toolbar across all three rich-text editors (function Vendor Information, Vendor Profile fields, and Chapter 29 vendor-added functions) to expose Quill formatting already bundled in the page but previously hidden behind a minimal bold/italic/list/link toolbar: a font-size picker (Small/Normal/Large/Huge), underline, strikethrough, text color and highlight/background color, blockquote, text alignment, video embedding (paste a YouTube/Vimeo URL), and a clear-formatting button. The image button remains excluded from the Chapter 29 function editor only, preserving its original simpler design. Extended the from-scratch Word (.docx) export generator to carry underline, strikethrough, and font size through into the exported file; text/background color and embedded video can't translate to a static document, so they degrade to plain text with an italic placeholder note, matching the existing pattern already used for images. Verified via a scripted pass exercising every new toolbar control (including the size picker, underline, color picker, and inserting a video via the built-in URL prompt) in both toolbar variants, confirming the no-image variant still correctly excludes only the image button, and running a full Word export against the resulting content with zero console errors. |
| 2026R1.41 | Added the ability to add and delete vendor-defined functions directly under each of the 28 standard Feature Matrix categories (distinct from Chapter 29, which creates an entirely new category) — a "+ Add Function" button on every category page opens the same evidentiary Function / Functional Requirement / Vendor Information / Status structure used throughout, and any function added this way can be freely edited or deleted since it is entirely vendor-authored. The categories themselves remain permanently fixed and cannot be removed. Added a non-destructive Hide/Unhide toggle for the 469 standard functions in place of deletion: a hidden function stays fully intact in the data (and still counts toward the LIMSpec Score if marked Documented), it only disappears from its category's visible list, with a small "N hidden \u2014 show hidden" link per category to reveal and manage them; this avoids the risk a true delete would carry of the function reappearing on a future Upgrade migration. Every count in the document now reflects both additions: the overall LIMSpec Score badge (cover banner, Vendor Profile chapter, sidebar nav), the Function Count Summary appendix table (each standard category row now shows "+N added" alongside its fixed count, with the grand total including everything), and each category's own live intro/score line. Generalized the shared Chapter 29 add/edit/delete modal to serve both use cases from one code path rather than duplicating it. Extended the Word export to include per-category vendor-added functions labeled "(Vendor Added)", and extended the Upgrade migration to carry both the hidden flag and per-category vendor-added functions through intact, verified by decoding an actual migrated file's data. Found and fixed a regression introduced earlier in this same change: inserting the new per-category "hidden functions" placeholder paragraph had silently broken the Word export's lookup for each category's descriptive paragraph (which relied on DOM sibling position) — caught and corrected before release. Verified via a comprehensive scripted pass: add/edit/delete of category-added functions with live score and summary-table checks at each step, hide/unhide with score-unchanged verification and the show/hide toggle link, a full regression pass confirming every original Chapter 29 flow still works identically after the shared-modal refactor, a Word export with zero console errors, and an end-to-end Upgrade migration test confirming hidden flags and vendor-added functions both survive intact. |
| 2026R1.42 | Added documentation for the 2026R1.41 feature to "The LIMSpec and How to Use It" tutorial chapter, which had been overlooked when that version shipped. Two new subsections were added after "Adding What the Standard Matrix Doesn't Cover": "Adding a Vendor-Specific Function Within a Standard Category," explaining the per-category "+ Add Function" button, how it differs from a Chapter 29 category, and that only the added functions (not the categories themselves) can be deleted; and "Hiding a Standard Function," explaining why hiding replaces deletion for the fixed 469 functions, that a hidden function stays fully intact in the data and still counts toward the LIMSpec Score if marked Documented, and both ways to unhide it (the toggle in the function's own modal, and each category's "Show hidden" link). Verified via a scripted pass confirming both new sections render correctly under the How to Use It chapter with zero console errors. |
| 2026R1.43 | The LIMSpec and How to Use It chapter had grown long and hard to navigate, so it was broken into four subchapters in the sidebar TOC \u2014 What Is the LIMSpec?, How a Lab Uses This Document, How a Vendor Uses This Document, and Keeping Your Profile Current \u2014 each linked to its existing section heading within the chapter, indented beneath the parent chapter link with a dash prefix. Added a chevron toggle button next to any chapter that has subchapters, letting the sidebar collapse or expand that chapter's subchapter list independently of navigating to it; clicking the chapter link itself still navigates normally, and clicking the chevron neither navigates nor scrolls the page. The toggle mechanism is generic (matches a chevron's data-toggle value against a subchapter-group's id), so any future chapter that gains subchapters can reuse the same pattern without new script. Verified via a scripted pass confirming all four subchapter links scroll to the correct heading, the chevron correctly toggles ARIA-expanded state and visibility on repeated clicks without affecting scroll position, and the parent chapter link's own navigation is unaffected, with zero console errors throughout. |
| 2026R1.44 | Fixed a bug where applying italic formatting in the Vendor Information Quill editor rendered the text bold instead of italic. The cause was a CSS rule scoped to the shared display-panel class used by both the Functional Requirement and Vendor Information panels, which overrode every <em> tag to render bold and non-italic \u2014 a leftover rule that no standard function's data actually relied on. Since Quill wraps italicized text in <em> tags, and the Vendor Information editor lives inside that same panel both while editing and when displaying saved content, every italic a vendor applied was silently being turned bold. Removed the override; italic now renders correctly as italic, normal-weight text. Verified via a scripted pass applying italic through the editor's keyboard shortcut and confirming correct computed style (italic, normal weight) both while editing and in the saved read-only view, confirming the Chapter 29 editor was unaffected (it was never in the affected panel) and continues to work correctly, and confirming an unrelated, intentionally-styled <em> rule elsewhere in the cover page was untouched by the fix. |
| 2026R1.45 | Replaced the two-option scoring system (Documented / Not Supported, 1/0 points) with a four-option system across the entire document: Off-the-Shelf (1 point), Configurable (1 point), Extensible (0.5 point), and Not Supported (0 points). Updated the VAC field-status dropdown, STATUS_META and STATUS_POINTS (and their Word-export equivalents WORD_STATUS_META / WORD_STATUS_POINTS), added a shared formatScore() helper so fractional totals display as, e.g., "12.5" rather than "12.5000000001" or an unnecessary decimal on whole numbers, and added new CSS pill/item-status classes (st-o, st-c, st-e) alongside the existing st-n. Every score computation that previously summed a binary Documented count now sums weighted points instead: updateVendorScore(), recomputeCategoryScore(), vacDocumentedCount(), categoryAddedDocumentedCount(), renderCategoryAdded(), renderVendorAdded(), and all three Word-export score blocks (standard category, category-added functions, and Chapter 29 vendor-added categories) now report a four-way breakdown ("N Off-the-Shelf, N Configurable, N Extensible, N Not Supported") alongside the weighted point total. Updated the Scoring Rubric chapter with the new four-row table and definitions, the "How to Use It" chapter's discussion of scoring discipline and the hide/unhide interaction with scoring, the Vendor Profile chapter's score explanation, and the Chapter 29 intro text (both the static HTML and its two JavaScript-driven variants) to describe weighted points rather than a binary count. The sourcesHtml absence-of-documentation check (keyed on st === 'n') required no change since Not Supported is still represented by the same n key. Appendix D historical rows were not modified. Verified via a scripted pass confirming the four-option dropdown renders correctly, weighted scores compute and display correctly (including fractional Extensible-only totals), and the Word export reflects the same four-way breakdown with zero console errors. |
| 2026R1.46 | Fixed a bug where a function's status badge (the small ✓/⚙/½/✕ symbol shown next to its icon in the category sidebar list) would not appear on page load unless the status had been set by interacting with the UI. The badge was only ever written by updateLiBadge(), called reactively from the status-change handler; the page's own initial-load routine looped over mfData to reconcile the hidden-function flag into the DOM (updateLiVisibility()) but never called updateLiBadge() for already-scored functions, so a profile whose mfData was populated by directly editing the underlying JSON (rather than through the modal UI) loaded with every sidebar badge missing even though the scores themselves were correct and the category totals computed correctly. Fixed by extending the existing load-time mfData.forEach loop with a single conditional call, if (item.st) { updateLiBadge(item); }, alongside the existing hidden-flag reconciliation — updateLiBadge() already safely no-ops into an update-in-place if a badge element happens to already exist, so this is additive and cannot double-insert a badge. Verified via node --check against all nine inline script blocks with zero syntax errors, and a scripted Playwright pass loading both a blank Master Template (0 badges rendered, as expected with nothing scored) and a fully-scored 469-function vendor profile (all 469 badges present immediately on load with no interaction, exact counts matching the underlying data, zero console or page errors). |
| 2026R1.47 | Added a Vendor Scoring Summary dashboard — four cards (Off-the-Shelf, Configurable, Extensible, Not Supported) showing the live count of functions currently at each rubric status — to the Vendor Profile chapter, positioned directly beneath the existing Vendor/Product LIMSpec Score badge. Counts are tallied across every source that already contributes to the overall LIMSpec Score: all 469 standard Feature Matrix functions (including hidden ones, matching the score's own long-standing behavior of still counting a hidden function if it has a status), any per-category vendor-added functions, and any Chapter 29 Vendor Added Categories. Implemented as a single new updateScoreDashboard() function called from inside the existing updateVendorScore() — the same pattern used since 2026R1.35 for the cover-banner and chapter badges — so the new dashboard required no new event wiring and updates automatically alongside the score itself on initial load, every function edit, every vendor-added function/category add-edit-delete, and after an Upgrade migration. Added matching CSS (a four-column grid, collapsing to two columns under 600px, using the same st-o/st-c/st-e/st-n accent colors already established for the sidebar status badges). Verified via a scripted Playwright pass: a blank Master Template shows all four counts at zero; the LabLynx vendor profile built earlier this session shows the dashboard matching its known breakdown (50/147/81/191) immediately on load with no interaction; and, most importantly, editing a single function's status live through the actual modal UI (Configurable → Not Supported) updated the dashboard (147→146, 191→192) and the LIMSpec Score (237.5→236.5) automatically and correctly with zero console errors, confirming the dashboard genuinely tracks live edits rather than only reflecting whatever was true at page load. |
| 2026R1.48 | Rebuilt the "Download Word Copy" export to be visually consistent with LIMSpec's own branding, replacing what had been a plain, unstyled document. Added a proper cover page: the embedded LIMSpec flask-and-checkmark logo, an orange "LIMSPEC VENDOR PROFILE" (or "LIMSPEC MASTER TEMPLATE" when blank) kicker label, the existing title, and a new bordered metadata block (Vendor/Product, Version, Generated date, and the live LIMSpec Score, computed once up front from the same WORD_STATUS_POINTS weights used elsewhere) framed by thin top/bottom rules matching the vendor-supplied reference design. Added real header and footer parts (previously absent entirely): a right-aligned "LIMSPEC — {VENDOR}" header and a centered "LIMSpec.com · Version {X} · Page {N}" footer using a genuine Word PAGE field, present on every page including the cover. Added an orange bottom-border rule to the Heading1 style (matching the reference document's accent treatment) and a new, currently-unused Heading2 style for future finer structure. Restyled every per-function table's "Function" row with a solid navy fill and white bold text, echoing the reference document's navy-header data tables. Colors were sourced from LIMSpec's own established brand (navy #1F3864, orange #E8622A) rather than copied directly from the reference document's LabLynx-specific shades, since the two are related but distinct brands. Implementation required extending runXml with color support, tcXml with a navy-shading option, and labeledRowXml to pass through cell-level styling options — all backward-compatible with existing call sites. Found and fixed two genuine OOXML schema defects in the process: the new cover metadata table and, more significantly, the long-standing general-purpose tblXml function used by every data table in the document were both missing the schema-required tblGrid element (previously silently auto-repaired by Word on open, only surfaced now under strict validation) — tblXml was corrected to compute a matching grid dynamically from actual column count rather than assuming a fixed shape, since it is shared by both the single-column function tables and the two-column Vendor Profile table. Also added a missing required w:gutter attribute to the page margin definition. Verified via node --check against all nine inline script blocks, an actual "Download Word Copy" click captured through a headless browser (not just code review), full OOXML schema validation (all checks passed after the two fixes above), and a rendered visual review of the resulting document — cover page, table of contents, function tables, and header/footer — across a 247-page fully-scored vendor profile and, separately, confirmation that the blank Master Template's export degrades correctly ("LIMSPEC MASTER TEMPLATE" kicker, "Not yet documented," "No Score," generic header) with zero console errors throughout. |
| 2026R1.49 | Added a 16th Vendor Profile field, "Link to Vendor LIMSpec," positioned immediately after "Support model," intended for a URL pointing to where this specific vendor's completed profile is published. Unlike every other Vendor Profile field, it does not use the Quill rich-text editor — the field-edit modal now checks a new type: 'link' property on the field's data and, when present, swaps the Quill container for a plain <input type="url"> instead, since a URL has no need for rich-text formatting. The value is stored as a plain URL string (not HTML) and rendered as a real, clickable anchor tag (target="_blank" rel="noopener") in the on-page table; the Word export renders it as a genuine OOXML hyperlink relationship via the existing hyperlinkXml() helper rather than passing it through the HTML-parsing path used by every other field. Left blank on both the Master Template and the already-completed LabLynx profile built earlier this session, since no real target URL exists yet for either — filling it in is a manual step for whoever publishes the finished profile. The existing field-migration logic required no changes: it already matches Vendor Profile fields by label and only copies the value key, so a newly-added field with no match in an older source file is simply left at its default (blank) value, and the new type property — which lives on the template's own current field definition, not on migrated data — is unaffected either way. Verified via node --check against all nine inline script blocks in both the Master Template and the LabLynx profile, a scripted Playwright pass confirming the modal correctly shows the URL input (and hides Quill) only for this field, that saving persists a plain URL string in the underlying JSON, that the on-page table renders it as a working link, and that a real "Download Word Copy" export produces a valid, schema-passing document with an actual hyperlink relationship pointing at the entered URL — confirmed directly in the exported file's word/_rels/document.xml.rels and a rendered visual check of the resulting page — with zero console errors throughout. |
