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

From LIMSWiki
Jump to navigationJump to search
Line 1: Line 1:
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.
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.)


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>
As dialogue continues with vendors, you'll have several points to address:


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 collection of critical requirements from the RFI to ensure those providers meet all or most of your needs. That said, 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.
1. What do I want their LIMS to do for me?


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:
2. How does their solution fit into our previously discussed budget?


* a table of contents;
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>:
* 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. Before submitting any RFI, your lab will want to conduct thorough internal research ensuring everyone understands what the current technology and processes are, and how you all want to shape that with the introduction or updating of laboratory informatics systems. (If your lab has limited to no experience with adding automation and informatics elements to a laboratory, you may want to read through laboratory informatics veteran Joe Liscouski's [[LII:The Application of Informatics to Scientific Work: Laboratory Informatics for Newbies|''The Application of Informatics to Scientific Work: Laboratory Informatics for Newbies'']] for further insight.) You'll also want to answer critical questions such as "who will be responsible for maintaining the solution and its security?" and "how will our processes and procedures change with the introduction or updating of informatics systems?". These and other questions make up your business considerations, which should also address the:
* 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.


* acquisition and long-term maintenance 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. (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).
* diversity of laboratory services offered now and into the future;
* level of in-house knowledge and experience with informatics systems and automation;
* level of in-house, executive buy-in of informatics adoption; and
* need for additional vendor pre-planning.


One other note: make it clear in any issued RFI that it's strictly a request for information and not a guarantee to issue a contract with any respondent.
: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.


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

Revision as of 19:16, 22 January 2022

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

  • 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. (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[3][4], 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-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.

References

  1. McLelland, A. (1998). "What is a LIMS - a laboratory toy, or a critical IT component?" (PDF). Royal Society of Chemistry. p. 1. Archived from the original on 04 October 2013. https://web.archive.org/web/20131004232754/http://www.rsc.org/pdf/andiv/tech.pdf. Retrieved 01 December 2021. 
  2. Joyce, J.R. (2010). "Industry Insights: Examining the Risks, Benefits and Trade-offs of Today’s LIMS". Scientific Computing (January/February 2010): 15–23. 
  3. Rosenberg, H.J. (28 March 2017). "How Much Does a LIMS Cost? Licensing and Beyond". SlideShare. https://www.slideshare.net/CSolsInc/how-much-does-a-lims-cost-licensing-and-beyond-pittcon-2017-tech-talk. Retrieved 01 December 2021. 
  4. "Saving Costs with LIMS". CSols, Inc. 25 October 2018. https://www.csolsinc.com/blog/saving-costs-with-lims/. Retrieved 01 December 2021.