User:Shawndouglas/sandbox/sublevel37 - Revision history

Shawndouglas at 20:58, 4 December 2021

2021-12-04T20:58:00Z

← Older revision		Revision as of 20:58, 4 December 2021
Line 136:		Line 136:
	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.		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 your lab's preparation and 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.		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.

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

Shawndouglas at 20:56, 4 December 2021

2021-12-04T20:56:05Z

← Older revision		Revision as of 20:56, 4 December 2021
Line 54:		Line 54:
	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.		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 4.3.1.) This naturally leads us to a discussion about the RFI process.		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.


Line 119:		Line 119:
	With much of this information in hand, you're likely ready to move on to finalizing the requirements specification and choosing a vendor, but not before you've sat through a few highly useful demonstrations.		With much of this information in hand, you're likely ready to move on to finalizing the requirements specification and choosing a vendor, but not before you've sat through a few highly useful demonstrations.

	===4.3.1 The value of demonstrations===		===6.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 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?).

Shawndouglas at 20:03, 4 December 2021

2021-12-04T20:03:29Z

← Older revision		Revision as of 20:03, 4 December 2021
Line 5:		Line 5:
	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.		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.

	==4.1 Conduct initial research into a specification document==
			==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.		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.

Line 56:		Line 57:


	==4.2 Issue some of the specification as part of a request for information (RFI)==		==6.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, 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 skip the RFI or RFP process and 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 towards your 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, 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 skip the RFI or RFP process and 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 towards your fact finding.

Line 84:		Line 85:


	==4.3 Respond to or open dialogue with vendors==		==6.3 Respond to or open dialogue with vendors==
	If you went the route of the RFI, you hopefully received more than a few well-crafted responses. Your RFI presumably included a small but critical set of requirements that needed to be addressed, and the vendors who responded dutifully addressed those critical requirements. Even if you didn't send out an RFI, you at least did your own research about some of the big players in the laboratory informatics space, and you may have even opened an initial dialogue with a few of them. If all has gone well, you're now at the point where you've narrowed down the pool of vendors but still have a basket of them to continue dialogue with. (If you're not comfortably at this point after an RFI or engagements with multiple vendors, you may need to either reconsider the effectiveness of your RFI or engagements or enlist help from a knowledgeable and experienced consultant to help steer you back on-course.)		If you went the route of the RFI, you hopefully received more than a few well-crafted responses. Your RFI presumably included a small but critical set of requirements that needed to be addressed, and the vendors who responded dutifully addressed those critical requirements. Even if you didn't send out an RFI, you at least did your own research about some of the big players in the laboratory informatics space, and you may have even opened an initial dialogue with a few of them. If all has gone well, you're now at the point where you've narrowed down the pool of vendors but still have a basket of them to continue dialogue with. (If you're not comfortably at this point after an RFI or engagements with multiple vendors, you may need to either reconsider the effectiveness of your RFI or engagements or enlist help from a knowledgeable and experienced consultant to help steer you back on-course.)

Line 126:		Line 127:


	==4.4 Finalize the requirements specification and choose a vendor==		==6.4 Finalize the requirements specification and choose a vendor==
	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.		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.

Shawndouglas at 20:56, 2 December 2021

2021-12-02T20:56:47Z

← Older revision		Revision as of 20:56, 2 December 2021
Line 133:		Line 133:
	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.		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.

	~~Again~~, ~~remember that often is the case when no single vendor can meet all~~ your ~~needs.~~		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.



	~~Your~~ specification document may look similar to the LIMSpec or in 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 your lab's preparation and 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.

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

Shawndouglas at 20:43, 2 December 2021

2021-12-02T20:43:35Z

← Older revision		Revision as of 20:43, 2 December 2021
Line 127:		Line 127:

	==4.4 Finalize the requirements specification and choose a vendor==		==4.4 Finalize the requirements specification and choose a vendor==
			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.

	Your specification document may look similar to the LIMSpec or in a slightly different format. ~~However~~, 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 is also included as part of this guide		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.

			Again, remember that often is the case when no single vendor can meet all your needs.



			Your specification document may look similar to the LIMSpec or in 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.

Shawndouglas at 03:34, 2 December 2021

2021-12-02T03:34:27Z

← Older revision		Revision as of 03:34, 2 December 2021
Line 128:		Line 128:
	==4.4 Finalize the requirements specification and choose a vendor==		==4.4 Finalize the requirements specification and choose a vendor==

	Your specification document may look similar to the LIMSpec or in a slightly different format. However, you'll want to give plenty of space for vendors to submit a response.		Your specification document may look similar to the LIMSpec or in a slightly different format. However, 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 is also included as part of this guide

Shawndouglas at 22:34, 1 December 2021

2021-12-01T22:34:14Z

← Older revision		Revision as of 22:34, 1 December 2021
Line 128:		Line 128:
	==4.4 Finalize the requirements specification and choose a vendor==		==4.4 Finalize the requirements specification and choose a vendor==

			Your specification document may look similar to the LIMSpec or in a slightly different format. However, you'll want to give plenty of space for vendors to submit a response.

Shawndouglas at 19:50, 1 December 2021

2021-12-01T19:50:56Z

← Older revision		Revision as of 19:50, 1 December 2021
Line 104:		Line 104:
	* configurability and cost-effectiveness: a user-configurable system (as opposed to hard-coded, requiring development for any modifications) that is flexible enough to adapt to rapid changes in test volume and type over time, without breaking the bank.		* configurability and cost-effectiveness: a user-configurable system (as opposed to hard-coded, requiring development for any modifications) that is flexible enough to adapt to rapid changes in test volume and type over time, without breaking the bank.

	As for the second question, budgeting is always a tricky topic, both internally and when discussing it with vendors. We already mentioned in the previous section that addressing the acquisition and long-term maintenance budget of your solution(s) must be addressed as part of your lab's business considerations. The fact that laboratory informatics systems like the LIMS or the [[laboratory information system]] (LIS) come in all kinds of price ranges makes it difficult to judge if a given system, as priced, is appropriate for your lab and its budget. There are some basic cost realities associated with LIMS or LIS acquisition<ref name="CSolsHowMuch17">{{cite web \|url=https://www.slideshare.net/CSolsInc/how-much-does-a-lims-cost-licensing-and-beyond-pittcon-2017-tech-talk \|title=How Much Does a LIMS Cost? Licensing and Beyond \|author=Rosenberg, H.J. \|work=SlideShare \|date=28 March 2017 \|accessdate=01 December 2021}}</ref><ref name="CSolsSaving18">{{cite web \|url=https://www.csolsinc.com/blog/saving-costs-with-lims/ \|title=Saving Costs with LIMS \|publisher=CSols, Inc \|date=25 October 2018 \|accessdate=01 December 2021}}</ref>, which will help you understand where the vendor price comes from, and how it figures into your lab's budget (though some of these concepts may also apply to other informatics systems).		As for the second question, budgeting is always a tricky topic, both internally and when discussing it with vendors. We already mentioned in the previous section that addressing the acquisition and long-term maintenance budget of your solution(s) must be addressed as part of your lab's business considerations. (And we already mentioned some cost considerations in 2.1.5; this discussion will add a few more points.) The fact that laboratory informatics systems like the LIMS or the [[laboratory information system]] (LIS) come in all kinds of price ranges makes it difficult to judge if a given system, as priced, is appropriate for your lab and its budget. There are some basic cost realities associated with LIMS or LIS acquisition<ref name="CSolsHowMuch17">{{cite web \|url=https://www.slideshare.net/CSolsInc/how-much-does-a-lims-cost-licensing-and-beyond-pittcon-2017-tech-talk \|title=How Much Does a LIMS Cost? Licensing and Beyond \|author=Rosenberg, H.J. \|work=SlideShare \|date=28 March 2017 \|accessdate=01 December 2021}}</ref><ref name="CSolsSaving18">{{cite web \|url=https://www.csolsinc.com/blog/saving-costs-with-lims/ \|title=Saving Costs with LIMS \|publisher=CSols, Inc \|date=25 October 2018 \|accessdate=01 December 2021}}</ref>, which will help you understand where the vendor price comes from, and how it figures into your lab's budget (though some of these concepts may also apply to other informatics systems).

	:1. Vendor pricing is generally based on how many will be using the system. This can be measured in concurrent users (how many will be using the system at any one time) or named users (the number of total users who will ever use the system, by name). Additionally, laboratory informatics vendors increasingly offer the option of a [[Cloud computing\|cloud-hosted]] subscription, which of course has the advantage of not requiring your own IT department, and allowing labs to defray cost over time, with little or no actual license fee. Think about your usage strategy and choose the pricing format that makes the most sense for you.		:1. Vendor pricing is generally based on how many will be using the system. This can be measured in concurrent users (how many will be using the system at any one time) or named users (the number of total users who will ever use the system, by name). Additionally, laboratory informatics vendors increasingly offer the option of a [[Cloud computing\|cloud-hosted]] subscription, which of course has the advantage of not requiring your own IT department, and allowing labs to defray cost over time, with little or no actual license fee. Think about your usage strategy and choose the pricing format that makes the most sense for you.
Line 130:		Line 130:


	~~==4.5 Extra considerations==~~

Shawndouglas at 19:40, 1 December 2021

2021-12-01T19:40:11Z

← Older revision		Revision as of 19:40, 1 December 2021
Line 104:		Line 104:
	* configurability and cost-effectiveness: a user-configurable system (as opposed to hard-coded, requiring development for any modifications) that is flexible enough to adapt to rapid changes in test volume and type over time, without breaking the bank.		* configurability and cost-effectiveness: a user-configurable system (as opposed to hard-coded, requiring development for any modifications) that is flexible enough to adapt to rapid changes in test volume and type over time, without breaking the bank.

	As for the second question, budgeting is always a tricky topic, both internally and when discussing it with vendors. We already mentioned in the previous section that addressing the acquisition and long-term maintenance budget of your solution(s) must be addressed as part of your lab's business considerations. The fact that laboratory informatics systems like LIMS come in all kinds of price ranges~~, making~~ it difficult to judge if a given system, as priced, is appropriate for your lab and its budget.		As for the second question, budgeting is always a tricky topic, both internally and when discussing it with vendors. We already mentioned in the previous section that addressing the acquisition and long-term maintenance budget of your solution(s) must be addressed as part of your lab's business considerations. The fact that laboratory informatics systems like the LIMS or the [[laboratory information system]] (LIS) come in all kinds of price ranges makes it difficult to judge if a given system, as priced, is appropriate for your lab and its budget. There are some basic cost realities associated with LIMS or LIS acquisition<ref name="CSolsHowMuch17">{{cite web \|url=https://www.slideshare.net/CSolsInc/how-much-does-a-lims-cost-licensing-and-beyond-pittcon-2017-tech-talk \|title=How Much Does a LIMS Cost? Licensing and Beyond \|author=Rosenberg, H.J. \|work=SlideShare \|date=28 March 2017 \|accessdate=01 December 2021}}</ref><ref name="CSolsSaving18">{{cite web \|url=https://www.csolsinc.com/blog/saving-costs-with-lims/ \|title=Saving Costs with LIMS \|publisher=CSols, Inc \|date=25 October 2018 \|accessdate=01 December 2021}}</ref>, which will help you understand where the vendor price comes from, and how it figures into your lab's budget (though some of these concepts may also apply to other informatics systems).

			:1. Vendor pricing is generally based on how many will be using the system. This can be measured in concurrent users (how many will be using the system at any one time) or named users (the number of total users who will ever use the system, by name). Additionally, laboratory informatics vendors increasingly offer the option of a [[Cloud computing\|cloud-hosted]] subscription, which of course has the advantage of not requiring your own IT department, and allowing labs to defray cost over time, with little or no actual license fee. Think about your usage strategy and choose the pricing format that makes the most sense for you.

			:2. Most costs are related to the work involved with installing, configuring, and migrating data to the system. Try to choose a solution that has what you need out of the box, as much as possible. The more customized or unique options you ask for up-front, the more it tends to cost, as extra items are a function of the time it takes developers to add them.

			:3. "User-configurable" beats "vendor-configurable" on cost-effectiveness. Some vendors offer a free or low-cost option, but don't be fooled. They are in business to make money, and they are counting on the fact that you'll need to pay them to make things work, add necessary functionality, and provide support and training. If you can find a vendor who offers a genuinely user-configurable system, and whose manuals and other support materials are clearly helpful and available so that you can adjust things the way you want, when you want, then that will go a long way toward budget efficiency and longevity.

			:4. Additional interfaces and reporting requirements cost money. If necessary, consider phasing in any additional instrument and software interfaces over time, as revenue eases cash flow. You can go live with your system operations more quickly, entering results manually until you can afford to interface your instruments one-by-one. This goes for reports as well; a simple reporting module that meets regulatory requirements will do. You can make your reports and other exportable documents more attractive later.

			Ideally, your budget has room for roughly $40- to $80,000 minimum (including setup, training, interfaces, etc.) for a quality, full-featured professional LIMS or LIS, with $300 to $900 per month (depending on number of users) for ongoing subscriptions. At around five concurrent users, the economics start to favor purchasing perpetual licenses rather than paying for a subscription. Purchased licenses will also entail ongoing annual or monthly costs as well (e.g., maintenance, support, warranty for updates etc.) Subscriptions (if available) are generally aimed at smaller labs. If you will be growing and scaling up, it may be a great way to get started, but make sure you have the option to switch to perpetual licenses later.

			With much of this information in hand, you're likely ready to move on to finalizing the requirements specification and choosing a vendor, but not before you've sat through a few highly useful demonstrations.

	===4.3.1 The value of demonstrations===		===4.3.1 The value of demonstrations===
Line 111:		Line 123:
	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.		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.

Shawndouglas at 19:23, 1 December 2021

2021-12-01T19:23:55Z

← Older revision		Revision as of 19:23, 1 December 2021
Line 85:		Line 85:

	==4.3 Respond to or open dialogue with vendors==		==4.3 Respond to or open dialogue with vendors==
	If you go the route of the RFI, you hopefully ~~receive~~ more than a few well-crafted responses. Your RFI presumably ~~had~~ a small but critical set of requirements		If you went the route of the RFI, you hopefully received more than a few well-crafted responses. Your RFI presumably included a small but critical set of requirements that needed to be addressed, and the vendors who responded dutifully addressed those critical requirements. Even if you didn't send out an RFI, you at least did your own research about some of the big players in the laboratory informatics space, and you may have even opened an initial dialogue with a few of them. If all has gone well, you're now at the point where you've narrowed down the pool of vendors but still have a basket of them to continue dialogue with. (If you're not comfortably at this point after an RFI or engagements with multiple vendors, you may need to either reconsider the effectiveness of your RFI or engagements or enlist help from a knowledgeable and experienced consultant to help steer you back on-course.)

			As dialogue continues with vendors, you'll have several points to address:

			1. What do I want their LIMS to do for me?

			2. How does their solution fit into our previously discussed budget?

			Regarding question one, you've already laid some of the groundwork for that with the help of your handful of critical requirements (and the associated research that went into developing them). Outside of those critical requirements, a laboratory informatics solution should also provide clearly definable benefits to how you operate your clinical diagnostics or research laboratory. These expected benefits should tie in with your overall business mission and goals. Using a [[laboratory information management system]] (LIMS) as an example, here are a few of the benefits a well-developed LIMS can provide to practically any laboratory. Whenever you go through the discovery process with a vendor, you'll be asking how their system provides these and other benefits through its functionality. A quality LIMS can provide<ref name="McLelland98">{{cite web \|url=http://www.rsc.org/pdf/andiv/tech.pdf \|archiveurl=https://web.archive.org/web/20131004232754/http://www.rsc.org/pdf/andiv/tech.pdf \|format=PDF \|title=What is a LIMS - a laboratory toy, or a critical IT component? \|author=McLelland, A. \|publisher=Royal Society of Chemistry \|page=1 \|date=1998 \|archivedate=04 October 2013 \|accessdate=01 December 2021}}</ref><ref name="SciCompRisksBens">{{cite journal \|title=Industry Insights: Examining the Risks, Benefits and Trade-offs of Today’s LIMS \|journal=Scientific Computing \|author=Joyce, J.R. \|issue=January/February 2010 \|pages=15–23 \|year=2010}}</ref>:

			* increased accuracy: the minimization or elimination of transcription and other errors;
			* streamlined processes: ensuring each process step in a protocol/method is completed in the proper order, with all requirements met, updating sample statuses automatically;
			* automation: integration with instruments, allowing for automatic uploading of samples and returning of results;
			* regulatory and standards compliance: functionality that aids with compliance, including reporting results to state and local authorities;
			* data security: role-based, configurable, secure access to data, processes, reporting, etc.;
			* flexible reporting: reporting tools that allows for the design and generation of certificates of authority and other reports to lab- and regulation-based specs;
			* instant data retrieval: query tools for finding data instantly according to any criteria (date range, test, product type, etc.); and
			* configurability and cost-effectiveness: a user-configurable system (as opposed to hard-coded, requiring development for any modifications) that is flexible enough to adapt to rapid changes in test volume and type over time, without breaking the bank.

			As for the second question, budgeting is always a tricky topic, both internally and when discussing it with vendors. We already mentioned in the previous section that addressing the acquisition and long-term maintenance budget of your solution(s) must be addressed as part of your lab's business considerations. The fact that laboratory informatics systems like LIMS come in all kinds of price ranges, making it difficult to judge if a given system, as priced, is appropriate for your lab and its budget.

	===4.3.1 The value of demonstrations===		===4.3.1 The value of demonstrations===