User:Shawndouglas/sandbox/sublevel4

LIMS requirement development is more than a laboratory wish list

When planning a project of any type, it makes perfect sense to initially research and detail the specifics of the project in order to lay a solid foundation to work from. This is particularly true with software development, where careful initial planning is vital to ensuring the project is legitimate in the eyes of critical stakeholders and will meet specified goals. This demands the creation of a software requirements specification.

Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something."^[1] Using our software development example again, from the perspective of software project stakeholders, this definition makes sense. Without this critical specification step, the software development project is sure to face the second most commonly cited reason for project failure: poor requirements management.^[2]

How should software developers approach their software requirements specification? The ISO/IEC/IEEE 29148:2018 standard describes the characteristics that make up quality software requirement development, including aspects such as^[3]:

correctly describing system behavior;
effectively removing ambiguity from the language used;
completely covering the system behavior and features;
accurately prioritizing and ranking the requirements; and
unequivocally ensuring the requirements are testable, modifiable, and traceable.

In the scope of developing and distributing a laboratory information management system (LIMS), the developer and distributor (i.e., the vendor) has a head-start on the targeted end user: the vendor has a standard to turn to in its requirements development. On the other hand, the laboratory seeking a LIMS doesn't really have such a standard for developing a set of requirements for their acquisition, and many labs won't even know they should develop a set of LIMS requirements before engaging the acquisition process.

The rest of this article will examine what a laboratory should consider in developing and using LIMS requirements as part of acquiring and implementing a LIMS.

What is a requirement, and what requirements are typically associated with a LIMS?

Broadly speaking, a requirement is a statement of a need, sometime accompanied by additional context. More formally, a software-based requirement typically begins with "the system/user/vendor shall/should ..." and focuses on a provided service, reaction to input, or expected behavior in a given use case of the software. The statement may be abstract (high-level) or specific and detailed to a precise function. The statement may also be of a functional nature, describing functionality or services in detail, or of a non-functional nature, describing the constraints of a given functionality or service and how it's rendered. An example of a functional software requirement could be "the user shall be able to query either all of the initial set of databases or select a subset from it." This statement describes specific functionality the system should have. On the other hand, a non-functional requirement, for example, may state "the system's query tool shall conform to the ABC 123-2019 standard." The statement describes a constraint placed upon the system's query functionality.^[4]

Over the years, a wide variety of companies, consultants, and researchers have compiled collections of requirement statements like these for laboratory informatics systems. These compiled lists of requirements for how a given laboratory informatics solution should be developed, implemented, and maintained have changed as technology and user demand have evolved. Historically, however, LIMS requirement lists have expanded to encompass a mix of "wishlist" requirements from laboratories seeking a LIMS, as well as regulation-mandated requirements. Over the years, the wishlist items haven't necessarily been ignored by developers, with many of them making their way into broader LIMS functionality. However, laboratories submitting these wishlist requirements do in fact need to prioritize them as "nice to have" or "essential to system operation," or something in between (more on this a bit later).^[5]^[6]^[7]

The end result is the functionality of a LIMS has evolved over the past few decades, and so have the requirements laboratories have for their LIMS. This evolution of software and requirement lists has found its way into several key places. One critical place to find such LIMS requirements is the ASTM E1578-18 Standard Guide for Laboratory Informatics, last updated in 2019.^[8] Its Appendix X1. "Laboratory Informatics Functional Requirements" makes for a great starting place for any lab seeking to acquire a LIMS or some other laboratory informatics solution. Another source for LIMS requirements is LIMSpec, which incorporates most of ASTM E1578 and adds requirements influenced by a wide variety of other standards, regulations, and guidelines. A sampling of some of the more crucial requirements found in LIMSpec includes^[9]:

1.18 The system shall have the ability to maintain the chain of custody of every sample, meaning the recording of every single sample distribution step to personnel—including details such as unique identifier, name, location, date, and time—while the sample is in the laboratory’s possession.

3.13 The system shall be able to record a complete record of all data created in the course of a test or experiment, including instruments used, calculations performed, and associated graphs, charts, and spectra. The record should also be able to capture the signatures of those who performed the test or experiment, as well as those who reviewed the record for compliance purposes.

7.1 The system shall be capable of creating, managing, and securely holding a variety of document types, while also allowing for the review and approval of those documents using version and release controls.

14.1 The system shall allow for accurate inventory management of all standards, reagents, and consumables used for laboratory testing. The system shall also be able to link manufacturer documents such as material safety data sheets and in-house instructions to their respective materials.

27.4 The system shall provide a guaranteed means to retrieve and restore archived data and metadata that is readable and accurate.

31.4 The system shall have a mechanism to securely retain data in the system for a specific time period and enable protections that ensure the accurate and ready retrieval of that data throughout the records retention period.

In both cases, the extensive collection of requirements are broken down into categories that take into account the various types of workflows, information technology demands, and regulatory demands a lab may have. They cover areas like^[8]^[9]:

sample entry, management, and tracking
results reviewing and verification
resource and inventory management
instrument and equipment management
system integration
scheduling and capacity planning
data integrity
system configuration and validation
cybersecurity and information privacy
specialty laboratory functions

Why bother with these types of requirement lists? The lab should be using them for several reasons. First, the laboratory implementing a solution like a LIMS should ensure that the software can help the lab achieve the goals it set forth when initially planning for a LIMS addition or upgrade. (More on that in the next section.) Second, developing your lab's list of critical LIMS requirements allows lab stakeholder the opportunity to learn more about what a LIMS is capable of doing. While some of this fact finding may be achieved in the early planning phases of LIMS acquisition, LIMS requirement development and use (more on that shortly) will result in further discoveries about laboratory informatics, and it may even reveal needs your lab didn't know it had. Finally, a solid set of LIMS requirements can act as a checklist in final LIMS acquisition decisions, as well as the resulting LIMS implementation and training.

How should labs develop their LIMS requirements?

Developing LIMS requirements requires initial planning, which should take into consideration any early discussions that justified the need for a LIMS, including overall laboratory goals driving LIMS acquisition or updating. That planning doesn't have to be rigid and clunky, but it should ideally include the following components.

Detail the lab's existing information management system or workflow-based processes (even if they are manual).
Define the associated information and data, and classify their criticality.
Identify current and previous information management policies and tools, as well as their effectiveness.
Identify the regulations, standards, and best practices affecting your laboratory operations and its digital assets.
Identify the laboratory's various practical workflows and detail how information management tools intersect and improve the workflows.
Perform a gap analysis of the current information management system or processes (i.e., define what needs are currently not being met).
Declare and describe objectives (i.e., goals) based on the outcomes of the above assessments, highlighting how you envision identified gaps should be filled.
Examine two or more requirements frameworks to gain further familiarity with laboratory informatics requirements, whether they're formal ones like ASTM E1578-18 and LIMSpec or informal requirements lists created by other laboratories.
Select and refine requirements based on the assessments, objectives, and policies highlighted prior.
Identify a handful of requirements as critical, some as medium-priority, and the rest as "wishlist" items.

Regarding that last point, your requirements list may very well looks like a list of non-negotiable necessities in most places, which is fine, at least initially. However, you may find that a LIMS vendor can't clearly meet each requirement, which makes having identified your requirements in a tiered fashion a useful task. Let's examine that a bit further.

How should labs put LIMS requirements to effective use?

You have your LIMS requirements documented, but how do you best put them to use during LIMS acquisition? The lab can certainly call up a LIMS vendor, ask for a demo and hand the vendor the full list right from the start. But this overtly direct approach may be a bit off-putting and not get quite the results you expect. Just as your time is valuable, so is the vendor's, and simply handing them a list of hundreds of requirements and asking them to reply can be daunting. This is where identifying a handful of critical requirements—and perhaps a few of those medium-priority requirements—truly comes in handy. Whether you reach out to vendors yourself or use a more formal request for information (RFI) or request for proposal (RFP) process to have major vendors approach your lab, having a relatively brief set of critical and medium-priority requirements in the initial stages of inquiry tends to lead to more fruitful results. Either way, your inquiry or RFI should be concise, direct, and honest, with practical questions or requests that are carefully chosen because they matter to your lab the most.^[10] Inevitably, you'll be turning to vendor demos and the short version of your LIMS requirements list in attempting to narrow down your search to a few quality vendor candidates, while learning more about each other.^[10] Once the pool of potential vendors is narrowed down, then you can feel more free to share your full list of requirements to ensure those providers meet your needs.

Be cognizant, however, that there may be no LIMS vendor that can meet each and every need of your lab. Your lab will have to make important decisions based upon those requirements you identified as non-negotiable and those you are more flexible in requiring. 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 in your industry. As such, those vendors with real-world experience developing systems for laboratories in your industry may have a strong leg up on other vendors, as they can make informed comments about your lab’s requirements based on their past experiences.