View source for Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research/Taking the next step/Conduct initial research into a specification document

==6. Taking the next step==
In section 2.4 of this guide, we briefly discussed how a user requirements specification (URS) fits into the process of purchasing laboratory informatics solutions for your clinical or research laboratory. The URS has been viewed as a means for the purchaser to ensure their needs are satisfied by the functionality of the software. Traditionally, this has turned into a "wish list" for the purchaser, which while somewhat practical still lacks in its finesse. One common problem in this wishlist approach is the risk of "requirements creep," where more functionality than is truly necessary is desired, inevitably leading to a state where no vendor can meet all the wishlisted requirements. This makes selecting a solution even more difficult, particularly without significant prioritization skills.<ref name="AasemAnalysis10">{{cite journal |title=Analysis and optimization of software requirements prioritization techniques |author=Aasem, M.; Ramzan, M.; Jaffar, A. |journal=Proceedings from the 2010 International Conference on Information and Emerging Technologies |pages=1–6 |year=2010 |doi=10.1109/ICIET.2010.5625687}}</ref><ref name="Hirsch10Steps13">{{cite web |url=https://www.phase2technology.com/blog/successful-requirements-gathering |title=10 Steps To Successful Requirements Gathering |author=Hirsch, J. |publisher=Phase2 Technology, LLC |date=22 November 2013 |accessdate=18 November 2021}}</ref><ref name="BurrissSoftware07">{{cite web |url=http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |archiveurl=https://web.archive.org/web/20190925003040/http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |title=Requirements Specification |work=CS451R, University of Missouri–Kansas City |author=Burris, E. |publisher=University of Missouri–Kansas City |date=2007 |archivedate=25 September 2019 |accessdate=18 November 2021}}</ref>

Noting the potential problems with this wishlist approach, LIMSpec—a specification document for laboratory informatics solutions—took a new approach and turned to standards and regulations that drive laboratories of all types, as well as the data they manage. LIMSpec was rebuilt based on [[ASTM E1578|ASTM E1578-18]] ''Standard Guide for Laboratory Informatics'', as well as dozens of other standards and regulations, while still leaving room for a software buyer to add their own custom requirements for their industry or lab. 

The rest of this chapter examines the research, documentation, and acquisition process that clinical and research labs needing laboratory informatics solutions will want to go through, with an emphasis on the utility of a sound requirements specification. While LIMSpec is offered as a solid starting point, you don't strictly need to use LIMSpec to conduct this process; the information in this chapter can largely be applied with or without LIMSpec itself.

===6.1 Conduct initial research into a specification document===
A specification is "a detailed precise presentation of something or of a plan or proposal for something."<ref name="MWSpec">{{cite web |url=https://www.merriam-webster.com/dictionary/specification |title=specification |work=Merriam-Webster |publisher=Merriam-Webster, Inc |accessdate=18 November 2021}}</ref> This concept of a specification as a presentation is critical to the laboratory seeking to find laboratory informatics software that fulfills their needs; they "present" their use case with the help of a requirements specification, and the vendor "presents" their ability (or inability) to comply through documentation and demonstration (more on that later). However, even the most seasoned of presenters at conferences and the like still require quality preparation before the presentation. This is where initial specification research comes into play for the lab.

Your lab's requirements specification document will eventually be a critical component for effectively selecting a laboratory informatics solution. There are numerous ways to approach the overall development of such a document. But why re-invent the wheel when others have already gone down that road? Sure, you could search for examples of such documents on the internet and customize them to your needs, or you and your team could brainstorm how a laboratory informatics solution should help your lab accomplish its goals. LIMSpec makes for one of the more thorough starting points to use, though you could also use other structured documents that have been developed by others. For the purposes of this guide, we'll look at LIMSpec.

The version of LIMSpec included in Appendix 1 of this guide is a slightly tweaked version of the original [[Book:LIMSpec 2019 R1|LIMSpec 2019]] document, omitting a few of the specialty laboratory functions that aren't applicable to clinical diagnostic and research laboratories. You'll note that it's 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 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)
** 18. Statistical trending and control charts
** 21. Forensic case and data management
** 22. 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. 

During the initial research towards your URS, you won't have to include every 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. In fact, you'll want to wait until after participating in several software demonstrations before even considering your URS to be complete. (More on that in 6.3.1.) This naturally leads us to a discussion about the RFI process.