Difference between revisions of "User:Shawndouglas/sandbox/sublevel37"

From LIMSWiki
Jump to navigationJump to search
Line 51: Line 51:
** 36. Information privacy
** 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. Additionally, you don't necessarily have to include every requirement in every subsection either. Vendors appreciate a more inviting approach, at least initially; you may want to go with a limited yet practical set of the requirements carefully chosen because they matter to you and your laboratory the most. This leads in well to a discussion about the RFI process.
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. Additionally, you don't necessarily have to include every requirement in every subsection either. Vendors appreciate a more inviting approach, at least initially; you will want to go with a limited yet practical set of the 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 or other specification document to be complete. (More on that in 4.3.1.) This leads in well to a discussion about the RFI process.




==4.2 Issue the specification as part of a request for information (RFI)==
==4.2 Issue some of the specification as part of a request for information (RFI)==
In some cases—particularly if your organization is of significant size—it may make sense to issue a formal RFI or request for proposal (RFP) and have laboratory informatics vendors approach your lab with how they can meet its needs. The RFI and RFP are traditional means towards soliciting bidding interest in an organization's project, typically containing the organization's specific requirements and vital questions that the bidder should be able to effectively answer. However, even if your organization chooses to do most of the investigative work of researching and approaching informatics vendors, turning to a key set of questions typically found in an RFI is extremely valuable for "fact finding."  
In some cases—particularly if your organization is of significant size—it may make sense to issue a formal RFI or request for proposal (RFP) and have laboratory informatics vendors approach your lab with how they can meet its needs. The RFI and RFP are traditional means towards soliciting bidding interest in an organization's project, typically containing the organization's specific requirements and vital questions that the bidder should be able to effectively answer. However, even if your organization chooses to do most of the investigative work of researching and approaching informatics vendors, turning to a key set of questions typically found in an RFI is extremely valuable for "fact finding."  


An RFI is an ideal means for learning more about a potential solution and how it can solve your problems, or for when you're not even sure how to solve your problem yet. However, the RFI should not be unduly long and tedious to complete for prospective vendors; it should be concise, direct, and honest. This means not only presenting a clear and humble vision of your own organization and its goals, but also asking just the right amount of questions to allow potential vendors to demonstrate their expertise and provide a clearer picture of who they are. Some take a technical approach to an RFI, using dense language and complicated spreadsheets for fact finding. However, as previously noted, you may want to limit the specified requirements in your RFI to those carefully chosen because they matter to you and your lab most.<ref name="HolmesItsAMatch">{{cite web |url=https://allcloud.io/blog/its-a-match-how-to-run-a-good-rfi-rfp-or-rfq-and-find-the-right-partner/ |title=It's a Match: How to Run a Good RFI, RFP, or RFQ and Find the Right Partner |author=Holmes, T. |work=AllCloud Blog |accessdate=30 November 2021}}</ref> Remember, however, that an RFI is not meant to answer all of your questions. The RFI is meant as a means to help narrow down your search to a few quality candidates while learning more about each other.<ref name="HolmesItsAMatch" /> Once the pool of potential software vendors is narrowed down, requirements can more broadly be added to the original critical requirements to ensure those providers meet all or most of your needs.  
An RFI is an ideal means for learning more about a potential solution and how it can solve your problems, or for when you're not even sure how to solve your problem yet. However, the RFI should not be unduly long and tedious to complete for prospective vendors; it should be concise, direct, and honest. This means not only presenting a clear and humble vision of your own organization and its goals, but also asking just the right amount of questions to allow potential vendors to demonstrate their expertise and provide a clearer picture of who they are. Some take a technical approach to an RFI, using dense language and complicated spreadsheets for fact finding. However, as previously noted, you will want to limit the specified requirements in your RFI to those carefully chosen because they matter to you and your lab the most.<ref name="HolmesItsAMatch">{{cite web |url=https://allcloud.io/blog/its-a-match-how-to-run-a-good-rfi-rfp-or-rfq-and-find-the-right-partner/ |title=It's a Match: How to Run a Good RFI, RFP, or RFQ and Find the Right Partner |author=Holmes, T. |work=AllCloud Blog |accessdate=30 November 2021}}</ref>  
 
Remember, an RFI is not meant to answer all of your questions. The RFI is meant as a means to help narrow down your search to a few quality candidates while learning more about each other.<ref name="HolmesItsAMatch" /> Once the pool of potential software vendors is narrowed down, and you then participate in their demonstrations, you then can broadly add more requirements to the original critical requirements from the RFI to ensure those providers meet all or most of your needs.  


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 clinical and research laboratories 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.
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 clinical and research laboratories 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.
Line 72: Line 74:


Being honest about your organization, it's informatics requirements, and its current technical environment upfront in the RFI or RFP will also ensure that the time spent on the process is optimized for all involved parties.
Being honest about your organization, it's informatics requirements, and its current technical environment upfront in the RFI or RFP will also ensure that the time spent on the process is optimized for all involved parties.


==4.3 Narrow down your vendor list and choose a vendor==
==4.3 Narrow down your vendor list and choose a vendor==
Line 78: Line 81:


===4.3.1 The value of demonstrations===
===4.3.1 The value of demonstrations===
A demonstration of laboratory informatics solution is an integral part of making your final decisions. The demo offers a unique and valuable opportunity to see in-person how data and information is added, edited, deleted, tracked, and protected within the context of the application; you can ask about how a function works and see it right then and there. Equally, it is an excellent time to compare notes with the vendor, particularly in regard to any requirements specification that was discussed prior. You can ask the vendor in real-time to ask questions about how a specific task is achieved or how a specific requirement is met (i.e., demonstrate to requirements), and the vendor can ask you about your lab's system and workflow requirements and how you best envision them being implemented in the system (e.g., does this interface seem intuitive?).
A demonstration of laboratory informatics solution is an integral part of making your final decisions. The demo offers a unique and valuable opportunity to see in-person how data and information is added, edited, deleted, tracked, and protected within the context of the application; you can ask about how a function works and see it right then and there. Equally, it is an excellent time to compare notes with the vendor, particularly in regard to the critical requirement that were addressed in your RFI (or through direct communication with the vendor). You can ask the vendor in real-time to answer questions about how a specific task is achieved, and the vendor can ask you about your lab's system and workflow requirements and how you best envision them being implemented in the system (e.g., does this interface seem intuitive?).


A demonstration is typically performed online, which is useful for a couple of reasons, COVID-19 notwithstanding. First, it means you can schedule and reschedule at your convenience, with little in the way of logistics to arrange. Second, the demonstration session is likely to be recorded (verify this), so everyone is clear on what was promised and what wasn't, how processes were shown to work, etc. Additionally, you can later review parts you may have missed, forgotten, or not quite understood, and you can share it with others, who then also get a look at the proposed system in action.
A demonstration is typically performed online, which is useful for a couple of reasons, COVID-19 notwithstanding. First, it means you can schedule and reschedule at your convenience, with little in the way of logistics to arrange. Second, the demonstration session is likely to be recorded (verify this), so everyone is clear on what was promised and what wasn't, how processes were shown to work, etc. Additionally, you can later review parts you may have missed, forgotten, or not quite understood, and you can share it with others, who then also get a look at the proposed system in action.
Be careful about falling for the temptation of presenting a full URS or other specification document to the vendor during the demonstration. You'll want to wait until after participating in several software demonstrations to consider presenting your full specification document to the vendor. By waiting until after the demos, a common error is avoided: too often labs think the first thing they must do is create a requirements list, then sit back and let the informatics vendors tell them how they meet it. Remember that even though most labs thoroughly understand their processes, they likely don't have as strong a grasp on the informatics portion of their processes and workflows. Participating in a demo before finalizing your list of specified requirements—or having only a minimal yet flexible requirements list during the demo—is a great way to later crosscheck the software features you have seen demonstrated to your lab's processes and any initial requirements specification you've made.<ref name="HammerHowTo19">{{cite web |url=https://www.striven.com/blog/erp-software-demo |title=How to Get the Most Value from an ERP Software Demo |author=Hammer, S. |work=The Takeoff |date=27 June 2019 |accessdate=07 July 2021}}</ref> After all, how can you effectively require medical diagnostic and research functions of your laboratory informatics software if you don't fully know what such an industry-specific system is capable of? You may end up adding several requirements to your final specifications document you later pass on to your potential vendors.




==References==
==References==
{{Reflist|colwidth=30em}}
{{Reflist|colwidth=30em}}

Revision as of 23:19, 30 November 2021

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.[1][2][3]

Noting the potential problems with this wishlist approach, LIMSpec—a specification document for laboratory informatics—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-18 Standard Guide for Laboratory Informatics, as well as dozens of other standards and regulations, while still leaving room for a purchaser to add their own custom requirements for their industry or lab.

The rest of this chapter examines the specification documentation and research process that clinical and research labs may want to go through, largely from the perspective of using LIMSpec as the base tool. However, you don't strictly need to use LIMSpec to conduct this documentation and research; the information in this chapter can largely be applied with or without LIMSpec itself.

4.1 Develop a specification document tailored to your lab's needs

A specification is "a detailed precise presentation of something or of a plan or proposal for something."[4] 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 through the specification, and the vendor "presents" their ability 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 the specification document comes into play for the lab.

Your lab's specification document—usually in the form of a user requirements specification (URS)—is the preparation to your presentation. There are numerous ways to approach the development of your specification documents, including brainstorming what your lab needs to be able to do with a laboratory informatics solution. But why re-invent the wheel when others have already go down that road? You could search for examples of such documents on the internet and customize them to your needs. The LIMSpec makes for one of the more thorough base documents to use, though you could use other example structured. 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 LIMSpec 2019 document, omitting a few of the specialty laboratory functions that aren't applicable to clinical 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. Additionally, you don't necessarily have to include every requirement in every subsection either. Vendors appreciate a more inviting approach, at least initially; you will want to go with a limited yet practical set of the 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 or other specification document to be complete. (More on that in 4.3.1.) This leads in well to a discussion about the RFI process.


4.2 Issue some of the specification as part of a request for information (RFI)

In some cases—particularly if your organization is of significant size—it may make sense to issue a formal RFI or request for proposal (RFP) and have laboratory informatics vendors approach your lab with how they can meet its needs. The RFI and RFP are traditional means towards soliciting bidding interest in an organization's project, typically containing the organization's specific requirements and vital questions that the bidder should be able to effectively answer. However, even if your organization chooses to do most of the investigative work of researching and approaching informatics vendors, turning to a key set of questions typically found in an RFI is extremely valuable for "fact finding."

An RFI is an ideal means for learning more about a potential solution and how it can solve your problems, or for when you're not even sure how to solve your problem yet. However, the RFI should not be unduly long and tedious to complete for prospective vendors; it should be concise, direct, and honest. This means not only presenting a clear and humble vision of your own organization and its goals, but also asking just the right amount of questions to allow potential vendors to demonstrate their expertise and provide a clearer picture of who they are. Some take a technical approach to an RFI, using dense language and complicated spreadsheets for fact finding. However, as previously noted, you will want to limit the specified requirements in your RFI to those carefully chosen because they matter to you and your lab the most.[5]

Remember, an RFI is not meant to answer all of your questions. The RFI is meant as a means to help narrow down your search to a few quality candidates while learning more about each other.[5] Once the pool of potential software vendors is narrowed down, and you then participate in their demonstrations, you then can broadly add more requirements to the original critical requirements from the RFI to ensure those providers meet all or most of your needs.

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 clinical and research laboratories 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.

Again, Appendix 1 of this guide includes a comprehensive specifications document called LIMSpec, from which you can draw the requirements that are most critical to be addressed in an RFI. If you have zero experience developing an RFI, you may want to first seek out various example RFIs on the internet, as well as some basic advice articles on the topic. Some websites may provide templates to examine for further details. Broadly speaking, if you're conducting a full RFI or RFP, you're going to lead with the standard components of an RFI or RFP, including:

  • a table of contents;
  • an honest introduction and overview of your organization, its goals and problems, and the services sought to solve them;
  • details on how the RFI or RFP evaluation process will be conducted;
  • basis for award (if an RFP);
  • the calendar schedule (including times) for related events;
  • how to submit the document and any related questions about it, including response format; and
  • your organization's background, business requirements, and current technical environment.

Being honest about your organization, it's informatics requirements, and its current technical environment upfront in the RFI or RFP will also ensure that the time spent on the process is optimized for all involved parties.


4.3 Narrow down your vendor list and choose a vendor

4.3.1 The value of demonstrations

A demonstration of laboratory informatics solution is an integral part of making your final decisions. The demo offers a unique and valuable opportunity to see in-person how data and information is added, edited, deleted, tracked, and protected within the context of the application; you can ask about how a function works and see it right then and there. Equally, it is an excellent time to compare notes with the vendor, particularly in regard to the critical requirement that were addressed in your RFI (or through direct communication with the vendor). You can ask the vendor in real-time to answer questions about how a specific task is achieved, and the vendor can ask you about your lab's system and workflow requirements and how you best envision them being implemented in the system (e.g., does this interface seem intuitive?).

A demonstration is typically performed online, which is useful for a couple of reasons, COVID-19 notwithstanding. First, it means you can schedule and reschedule at your convenience, with little in the way of logistics to arrange. Second, the demonstration session is likely to be recorded (verify this), so everyone is clear on what was promised and what wasn't, how processes were shown to work, etc. Additionally, you can later review parts you may have missed, forgotten, or not quite understood, and you can share it with others, who then also get a look at the proposed system in action.

Be careful about falling for the temptation of presenting a full URS or other specification document to the vendor during the demonstration. You'll want to wait until after participating in several software demonstrations to consider presenting your full specification document to the vendor. By waiting until after the demos, a common error is avoided: too often labs think the first thing they must do is create a requirements list, then sit back and let the informatics vendors tell them how they meet it. Remember that even though most labs thoroughly understand their processes, they likely don't have as strong a grasp on the informatics portion of their processes and workflows. Participating in a demo before finalizing your list of specified requirements—or having only a minimal yet flexible requirements list during the demo—is a great way to later crosscheck the software features you have seen demonstrated to your lab's processes and any initial requirements specification you've made.[6] After all, how can you effectively require medical diagnostic and research functions of your laboratory informatics software if you don't fully know what such an industry-specific system is capable of? You may end up adding several requirements to your final specifications document you later pass on to your potential vendors.


References

  1. 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. 
  2. Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. https://www.phase2technology.com/blog/successful-requirements-gathering. Retrieved 18 November 2021. 
  3. Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. Archived from the original on 25 September 2019. https://web.archive.org/web/20190925003040/http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 18 November 2021. 
  4. "specification". Merriam-Webster. Merriam-Webster, Inc. https://www.merriam-webster.com/dictionary/specification. Retrieved 18 November 2021. 
  5. 5.0 5.1 Holmes, T.. "It's a Match: How to Run a Good RFI, RFP, or RFQ and Find the Right Partner". AllCloud Blog. https://allcloud.io/blog/its-a-match-how-to-run-a-good-rfi-rfp-or-rfq-and-find-the-right-partner/. Retrieved 30 November 2021. 
  6. Hammer, S. (27 June 2019). "How to Get the Most Value from an ERP Software Demo". The Takeoff. https://www.striven.com/blog/erp-software-demo. Retrieved 07 July 2021.