From LIMSWiki
(Redirected from Limspec)
Jump to navigationJump to search
Original author(s) LabLynx, Inc.
Developer(s) Douglas, S.E.
Initial release June 7, 2007 (2007-06-07)[1]
Stable release 2022 R2 / December 2022; 18 months ago (2022-12)
License(s) Creative Commons Attribution-ShareAlike 4.0 International
Website LIMSpec 2022 R2 (wiki)
LIMSpec 2022 R2 (.docx)
LIMSpec 2022 R2 (eBook)

LIMSpec is a laboratory-focused, standards-and-regulations-based user requirements specification (URS) for laboratory informatics software solutions, created to make choosing such software solutions easier and provide practical real-world context for what drives laboratory software development, particularly for regulated industries.


LIMSpec was originated by the Laboratory Informatics Institute in 2007, intended to ultimately serve as a complete tool for managing the laboratory's evaluation process for laboratory information management system (LIMS) and laboratory information system (LIS) selection. Initially, it was focused on cataloging requirements and vendor questions, and released under a Creative Commons license allowing for the categorization and assignment of requirement to specific industries. In later versions, users could create their own private collection of requirements and questions, and export that collection in a variety of formats.

LIMSpec has taken on many different iterations over the years. When originally released in 2007, it was a collection of Microsoft Word documents and eBooks (available on a mailed CD), containing numbered user requirements that could be coded as mandatory, optional, or possible future requirement by the lab, and coded as meeting the requirement, meeting the requirement with customization, or not meeting the requirement by the vendor. Sections were color-coded to delineate who was responsible for completing what.[1] By 2011, development of LIMSpec and its requirements was opened up to the laboratory informatics community on LinkedIn.[2] Further efforts to open up LIMSpec development occurred in the mid-2010s, for example on GitHub[3] and a MediaWiki installation[4], giving laboratorians and other stakeholders a more direct online path to engaging with LIMSpec development and use.

By 2019, a significant shift in approach to LIMSpec was enacted, driven in part by the 2018 release of ASTM E1578-18 Standard Guide for Laboratory Informatics. That standard included a Laboratory Informatics Functional Requirements checklist for laboratory informatics solutions, making a great foundation for LIMSpec's transformation into a user requirements specification (URS) strictly based off of standards and regulatory sources affecting how laboratories are run. September 2019 saw the release of LIMSpec 2019 R1, based on 70 different sources and made available on LIMSwiki and in a downloadable book format on LIMSforum.[5] With the latest iteration—LIMSpec 2022 R2—adding more than 30 new sources of standards and compliance, LIMSpec continues to grow as a LabLynx-supported URS based on real-world needs of laboratories.


Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something."[6] In other words, an existing or theoretical product, concept, or idea is presented in detail for a particular audience. In a broad sense, detailing the specifics about a project, concept, or idea to others is just common sense. This applies just as well to the world of software development, where a software requirements specification is essential for preventing the second most commonly cited reason for project failure: poor requirements management.[7]

Over the years, a wide variety of companies, consultants, and researchers have compiled public and private software requirements specifications for laboratory informatics systems. These compiled lists of requirements for how a given laboratory informatics solution should be developed, delivered, and maintained have changed as technology and user demand have evolved. Often times, these requirements documents turn into a mix of "wishlist" requirements from potential and active clients, as well as regulation-mandated requirements. The wishlist items aren't necessarily ignored by developers, but they do in fact have to be prioritized as "nice to have" or "essential to system operation," or something in between.[8][9][10] While this reasonable mix of requirements has served informatics software developers well[11] (including for past iterations of LIMSpec), sometimes a fresh approach is required. Why not tie a software solution's functionality to the requirements of meeting laboratory standards, regulations, guidelines, and best practices?

The latest iteration of LIMSpec is grounded in ASTM E1578-18 Standard Guide for Laboratory Informatics at its core, with more than 130 additional sources being tapped into, including 21 CFR Part 11, ISO 15189, and Safe Food for Canadians Regulations, as well as various E.U. Commission Directives and World Health Organization (WHO) Technical Reports. As additional sources get added to LIMSpec, it becomes even more robust and relevant to more industries with laboratories. Those sources are linked to one or more individual requirement statements spanning multiple aspects of laboratory operations (see the screenshot in the information box, above). In some cases, the standards and guidelines covered are proprietary. In those cases, the standard was either purchased for review or heavily researched using supporting documentation, and the link goes to the acquisition page for the standard. In other cases, some sources have been intentionally omitted due to their proprietary nature or cost. For example, the AOAC International Official Methods of Analysis and Guidelines for Laboratories Performing Microbiological and Chemical Analyses of Food, Dietary Supplements, and Pharmaceuticals are both proprietary and more or less prohibitively expensive. In other cases, such as with the U.S. Food Emergency Response Network and Laboratory Response Network, they simply don't make their standardized procedures open to the public and thus can't be included.

The LIMSpec is maintained and added to periodically as time allows and necessity dictates.


The LIMSpec 2022 R2 document is divided into five distinct sections, with numerous subsections in each:

  • Primary Laboratory Workflow
    • 1. Sample and experiment registration
    • 2. Sample management
    • 3. Core laboratory testing and experiments
    • 4. Results review and verification
    • 5. Sample, experiment, and study approval and verification
    • 6. Reporting
  • Maintaining Laboratory Workflow and Operations
    • 7. Document and records management
    • 8. Resource management
    • 9. Compliance management
    • 10. Instrument and equipment management
    • 11. Batch and lot management
    • 12. Scheduled event management
    • 13. Instrument data capture and control
    • 14. Standard and reagent management
    • 15. Inventory management
    • 16. Investigation and quality management
  • Specialty Laboratory Functions (minus non-relevant industries)
    • 17. Production management
    • 18. Statistical trending and control charts
    • 19. Agriculture and food data management
    • 20. Environmental data management
    • 21. Forensic case and data management
    • 22. Clinical and public health data management
    • 23. Veterinary data management
    • 24. Scientific data management
    • 25. Health information technology
  • Technology and Performance Improvements
    • 26. Instrument data systems functions
    • 27. Systems integration
    • 28. Laboratory scheduling and capacity planning
    • 29. Lean laboratory and continuous improvement
    • 30. Artificial intelligence and smart systems
  • Security and Integrity of Systems and Operations
    • 31. Data integrity
    • 32. Configuration management
    • 33. System validation and commission
    • 34. System administration
    • 35. Cybersecurity
    • 36. Information privacy

These sections and subsections should be able to address most any requirement you have for your system. Of course, if something isn't covered by LIMSpec, you can always add additional requirements.

Using LIMSpec

As noted, LIMSpec's requirement are all based on not just the ASTM E1578 standard but also a wide variety of other sources. That ultimately means a foundational reasoning is provided for each requirement, not necessarily a "just because I want it" reasoning. As foundational requirements, LIMSpec should thus operate as an excellent starting point for building your own URS or for researching the best laboratory informatics solution for your laboratory. Some laboratories may want to look at LIMSpec as a checklist of possible requirements for a LIMS or LIS they are shopping for, or they may want to use LIMSpec as a base for a request for information (RFI) directed at laboratory informatics vendors.

In either case, an initial set of critical requirements will be born out of using a specification document like LIMSpec to develop your URS. It is more work to go this route, but turning to an initial URS leaves less to chance.[12] Developing your own URS isn't always straightforward. During the initial research towards your URS, you won't have to (and shouldn't) include every LIMSpec requirement for when you approach potential vendors. Most vendors appreciate a more inviting approach that doesn't overwhelm, at least initially. You will want to go with a limited yet practical set of requirements carefully chosen because they matter to you and your laboratory the most. Wherever you choose to start, you'll likely want to wait until after participating in several software demonstrations before even considering your URS to be complete. However, whatever the URS looks like in the end, it's ultimately up to the vendor to be able to demonstrate how the software does and does not meet its requirements.

If issuing an RFI, again, the user will want to carefully select LIMSpec requirements that are most critical to its laboratory operations. For example, a lab complying with ISO/IEC 17025 may want to focus on requirements specific to that standard, at least initially. Remember, an RFI is not meant to answer all of your questions in the initial discovery phase. The RFI is meant as a means to help narrow down your search to a few quality candidates while learning more about each other.[13] Once the RFI process is complete, software demonstrations have been attended, and the pool of potential software vendors is narrowed down, you then can broadly add more requirements to the original collection of critical requirements from the RFI to ensure those providers meet all or most of your needs. That said, be cognizant that there may be no vendor that can meet each and every need of your lab. Your lab will have to make important decisions about which requirements are non-negotiable and which are more flexible. The vendors you engage with may be able to provide realistic advice in this regard, based upon your lab's requirements and their past experience with labs. As such, those vendors with real-world experience meeting the needs of your laboratory's industry may have a strong leg up on other vendors.


  1. 1.0 1.1 Jones, J.H. (26 June 2007). "Develop your LIMS Requirements with the LIMSpec Library". Archived from the original on 26 April 2016. Retrieved 28 February 2023. 
  2. " - LIMS requirements development and discussion group". LinkedIn Corporation. Archived from the original on 03 February 2011. Retrieved 28 February 2023. 
  3. "LIMSforge/LiMSpec". GitHub. Archived from the original on 28 April 2015. Retrieved 28 February 2023. 
  4. "Welcome to the Limspec Wiki, a repository of specifications and more for informatics software". LIMSpec Wiki. 27 April 2015. Archived from the original on 02 August 2015. Retrieved 28 February 2023. 
  5. Douglas, S.E. (20 September 2019). "LIMSpec 2019 R1". LIMSwiki. Retrieved 28 February 2023. 
  6. "specification". Merriam-Webster. Merriam-Webster, Inc. Retrieved 28 February 2023. 
  7. Bieg, D.P. (August 2014). "Introduction" (PDF). Requirements Management: A Core Competency for Project and Program Success. Project Management Institute. p. 3. Retrieved 28 February 2023. 
  8. Aasem, M.; Ramzan, M.; Jaffar, A. (2010). "Analysis and optimization of software requirements prioritization techniques". Proceedings from the 2010 International Conference on Information and Emerging Technologies: 1–6. doi:10.1109/ICIET.2010.5625687. 
  9. Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. Retrieved 28 February 2023. 
  10. Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. Archived from the original on 24 July 2019. Retrieved 28 February 2023. 
  11. Hofmann, H.F.; Lehner, F. (2001). "Requirements engineering as a success factor in software projects". IEEE Software 18 (4): 58–66. doi:10.1109/MS.2001.936219. 
  12. Schmitt, S. (2018). "User Requirements Specifications–How Difficult Can It Be?". Pharmaceutical Technology 42 (11): 58. Retrieved 28 February 2023. 
  13. Holmes, T.. "It's a Match: How to Run a Good RFI, RFP, or RFQ and Find the Right Partner". AllCloud Blog. Retrieved 28 February 2023.