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

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
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?).
Now that the demonstrations have been conducted and more questions asked, you should be close to finalizing your requirement specifications with one ore more vendors. In fact, you may have taken LIMSpec, chosen a few critical requirements from it, added them to a few unique requirements of your own, and included them as part of an RFI or question and answer session with vendors. You then likely took those responses and added them to your wider overall specification (e.g., LIMSpec), along with your own notes and observations from interacting with the vendor. This may have been repeated for several vendors and their offerings.  


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.
At this point, you're likely ready to either have those vendors complete the rest of the responses for their corresponding URS, or you may even be ready to narrow down your vendor selection. This all likely depends on what the initial fact finding revealed. How well did the vendors respond to your laboratory's unique set of needs? Were there critical areas that one vendor could address with their off-the-shelf solution but another vendor would have to address with custom coding? Did any of the vendors meet your budget expectations? Have you followed up on any references and customer experiences the vendors provided to you?


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, and that's assuming that you've grown enamored with their solution. By waiting to finalize your lab's requirements specification 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 specific 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? After the demonstrations, you may end up adding several requirements to your final specifications document, which you later pass on to your potential vendors of choice for final confirmation.
It may be that several vendors are appealing at this point, meaning it's time to have them respond to the rest of the URS. This makes not only for good due diligence, to better ensure most requirements can be met, but also a reviewable option for any "tie-breaker" you have between vendors. In reality, this tie-breaker scenario would rarely come up; more often, some other aspect of the software, company, or pricing will be a stronger limiter. However, you still want to get all those vendor responses, even if you've early on filtered your options down to one vendor.


==References==
Ultimately, your specification document may look similar to the LIMSpec, or it may have a slightly different format. Many prospective buyers will develop a requirement specification in Microsoft Excel, but that has a few minor disadvantages. Regardless of format, you'll want to give plenty of space for vendors to submit a response to each requirement. For your convenience, a Microsoft Word version of Appendix 1's LIMSpec for medical diagnostics and research labs is also included as part of this guide (see A1.8 LIMSpec in Microsoft Word format). That document is editable, giving end users and vendors the flexibility to remove information and enlarge columns.
{{Reflist}}
 
Additionally, remember that often is the case that after the URS is completed and final questions asked, no single vendor can meet all your needs. Be ready for this possibility, whether it be a functionality requirement or a budget issue. Know ahead of time where your laboratory is willing to be flexible, and how much flex you have. After all of your lab's preparation, and with a little luck, you've found a vendor that fits the bill, even if a few minor compromises had to be made along the way.
 
 
==Citation information for this chapter==
'''Chapter''': 6. Taking the next step
 
'''Title''': ''Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research''
 
'''Edition''': 2022 Edition
 
'''Author for citation''': Shawn E. Douglas and Alan Vaughan
 
'''License for content''': [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
 
'''Publication date''': January 2022
 
<!--Place all category tags here-->

Revision as of 19:18, 22 January 2022

Now that the demonstrations have been conducted and more questions asked, you should be close to finalizing your requirement specifications with one ore more vendors. In fact, you may have taken LIMSpec, chosen a few critical requirements from it, added them to a few unique requirements of your own, and included them as part of an RFI or question and answer session with vendors. You then likely took those responses and added them to your wider overall specification (e.g., LIMSpec), along with your own notes and observations from interacting with the vendor. This may have been repeated for several vendors and their offerings.

At this point, you're likely ready to either have those vendors complete the rest of the responses for their corresponding URS, or you may even be ready to narrow down your vendor selection. This all likely depends on what the initial fact finding revealed. How well did the vendors respond to your laboratory's unique set of needs? Were there critical areas that one vendor could address with their off-the-shelf solution but another vendor would have to address with custom coding? Did any of the vendors meet your budget expectations? Have you followed up on any references and customer experiences the vendors provided to you?

It may be that several vendors are appealing at this point, meaning it's time to have them respond to the rest of the URS. This makes not only for good due diligence, to better ensure most requirements can be met, but also a reviewable option for any "tie-breaker" you have between vendors. In reality, this tie-breaker scenario would rarely come up; more often, some other aspect of the software, company, or pricing will be a stronger limiter. However, you still want to get all those vendor responses, even if you've early on filtered your options down to one vendor.

Ultimately, your specification document may look similar to the LIMSpec, or it may have a slightly different format. Many prospective buyers will develop a requirement specification in Microsoft Excel, but that has a few minor disadvantages. Regardless of format, you'll want to give plenty of space for vendors to submit a response to each requirement. For your convenience, a Microsoft Word version of Appendix 1's LIMSpec for medical diagnostics and research labs is also included as part of this guide (see A1.8 LIMSpec in Microsoft Word format). That document is editable, giving end users and vendors the flexibility to remove information and enlarge columns.

Additionally, remember that often is the case that after the URS is completed and final questions asked, no single vendor can meet all your needs. Be ready for this possibility, whether it be a functionality requirement or a budget issue. Know ahead of time where your laboratory is willing to be flexible, and how much flex you have. After all of your lab's preparation, and with a little luck, you've found a vendor that fits the bill, even if a few minor compromises had to be made along the way.


Citation information for this chapter

Chapter: 6. Taking the next step

Title: Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research

Edition: 2022 Edition

Author for citation: Shawn E. Douglas and Alan Vaughan

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: January 2022