LII:Laboratory Informatics Software Acquisition and Implementation Considerations

Starting out

The two main questions you will need to answer at the outset are:

1. What do I want the laboratory informatics solution to do for me?

2. What kind of budget do I have?

Additionally—and secondarily—you'll want to be sure you can participate in one or more vendor demonstrations and, afterwards, build a requirements list.

Features and benefits

The answer to the first question is largely the same as most other kinds of labs. The benefits of laboratory informatics software include:

• increased accuracy, with a minimization or elimination of transcription and other errors;
• streamlined processes, where each step in a protocol or method is completed in the proper order, with all requirements met, updating statuses automatically;
• automation of integrated instruments, allowing for automatic uploading of samples/specimens and processing of results;
• regulatory and standards compliance for your procedures helps keep you doing the right things the right ways, while tracking history so you can provide documentation when you need to;
• data security via configurable role-based secure access to data, processes, reporting, etc.;
• custom reporting tools, which allow you to design and generate reports to your own specifications, incorporating exactly the information you want;
• instant data retrieval, allowing you to search and call up any information instantly according to any criteria (date range, test, product type, etc.), particularly useful during audits; and
• cost-effectiveness through improved efficiency and accuracy, which means less waste of time, and if a user-configurable system (as opposed to hard-coded, requiring development for any modifications), its return on investment {ROI) increases over time, due to built-in adaptability and thus longevity.

Budgeting

The second question of budget is more difficult to answer by the fact that laboratory informatics software comes in all kinds of price ranges, from over $1 million all the way down to free. How are you supposed to honestly judge where the appropriate system price for your lab lies?

There are some basic realities that can help in figuring an appropriate budget, however.

1. A rough sense of price can generally be based on how much ownership you want in the software itself and how many will be using the laboratory informatics solution.

Ownership: Buying versus renting: There are two primary ways to price laboratory informatics software: a one-time license fee or a subscription (cloud-hosted software as a service or SaaS ). If you have your own dedicated IT department and staff, you may prefer the former. Otherwise, a SaaS-based subscription may well be the better and more cost-effective way to go (no IT costs at all other than internet access). This item will be part of your up-front cost and, in the case of a subscription, it will also figure in your first year and ongoing costs. A vendor may have a subscription fee of say $500, with the initial month due at signing. However, more often the vendor may require three months or even the first year up front, so be prepared to factor that into up-front costs. However, it still is almost always less expensive at the outset (and over time, if you factor in IT and service costs) than paying for a license fee.

User numbers: Named versus concurrent: In addition to the two types of software pricing above, there are pricing sub-types. Generally these are based on the number of users (or, in some cases, "nodes," which are simply any entities that access the software, including other systems, instruments, etc.). How these are counted can vary. They may be counted as "named" users, which bases pricing on the actual individual users of the system, even if they may only log in once in awhile. Users typically may not use each other's logins (this is prohibited regardless of pricing structure, for GxP and other standard- and regulatory-based reasons). They may also be counted as "concurrent" users, which bases pricing on the maximum number of users who will be logged in at any given time. You can define an unlimited number of named users in the system, each with their own login credentials. However, only the number of (concurrent) users specified in the license/subscription may be logged in at any one time. For example, you may have 10 staff, but due to work processes, shifts, etc., only up to six might ever be logged in simultaneously. Whereas this would require a named user license for 10, it would only require a concurrent user license for six. Finally, you may have the option for "unlimited" users. This may be useful for huge labs (typically 30 to 50 and up), where the license or subscription may simply be a flat fee that allows any number of users.

2. Most costs are related to work. 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, the more it costs, because extra items are a function of the time it takes developers to add them.

3. User-configurable solutions beat vendor-configurable solutions on cost-effectiveness. Many software 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, support, training, etc. If you can find one who offers a genuinely user-configurable solution, and whose manuals and other support materials are clearly helpful and available so you can adjust things the way you want, when you want, then that will go a long way toward budget efficiency and longevity.

4. Interfaces cost money. If necessary, consider whether it's feasibly or not to phase in those instrument and other interfaces over time, as revenue eases cash flow. You may be able to go live with your laboratory informatics solution more quickly, entering results manually until you can afford to interface your instruments one-by-one. This goes for reports too. A standard report will do. You can make fancy ones later.

Pricing will vary depending on what kind of solution you need. For example, you'll probably want to budget a minimum of around $40,000 to $80,000 plus or minus, minimum, (including setup, training, interfaces, etc.) for a decent, bang-for-your-buck laboratory information management system (LIMS) with maybe an interface or two, plus an additional $300 to $900 per month (depending on number of users) for ongoing subscriptions. At around five concurrent (logged in at the same time) users, the economics start to favor purchasing perpetual licenses rather than paying subscription. Purchased licenses will also entail ongoing annual or monthly costs as well (maintenance, support, warranty for updates etc.), but somewhere around that number of users it may tend to be cheaper than a subscription option. 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 ensure you have the option to switch to perpetual licenses later.

Demonstration and requirements

You no doubt are quite familiar with all of your lab's or potential lab's processes, but that doesn't mean you necessarily have even an inkling about how exactly a laboratory informatics solution fits into your workflow. That's pretty common, and it's fine. That's what software companies should be able to show you. A good developer already generally understands your kind of lab but will ask you a lot of questions about exactly how you do things. It's the exceptions that need catering to. Doing a live demo (online is actually even better than in-person; it can be recorded so you can review and share it as much as you want) is a great context for exploring how a candidate software solution performs the functions your lab needs. It is interactive and live, so there can be no tricks—you see just how it performs in real time, and you can throw as many intricate scenarios at the developer as you like. The demo experience can go a long way towards giving you a real feel for the software's suitability. Additionally, you can both (laboratory and vendor) gain a budgetary idea of cost based on what you do, what you want the software to do, what it can do, as well as the product and services pricing itself.

One note: too often labs think the first thing they must do is create a requirements list, then sit back and let the software vendors tell them how they meet those requirements. As mentioned earlier, even though laboratory personnel understand their lab and its processes, most don't have much of a clue about laboratory informatics and workflow integration. Participating in a a demo before creating the requirements list is a great way to plug in the features you have seen demonstrated to your lab's to your own processes and needs. After all, how can you effectively require specific functions if you don't fully know what a given laboratory informatics tool is capable of? After the demo, you are much more equipped to create a requirements list that becomes the contractual product set and statement/scope of work (SOW) that represents your laboratory informatics solution.

Implementation

Features, budget, and requirements aside, you'll also want to consider what implementation details will affect your overall bottom line. There are two main keys to successful implementation: having an accurate SOW and high team availability.

1. Accurate SOW: A statement of work or SOW describes the work that will be done by the vendor, including milestones, deliverables, and any other end products and services. It should be absolutely clear in both your and the vendor's minds exactly what the delivered, operational laboratory informatics solution should look like. If possible, ask for a validation script that addresses each function and process. Read through it and make sure you agree with each test, that it is an effective measure of the software function it purports to validate. If not, work with the vendor to modify it to your satisfaction. Remember, vendors are required to meet exactly what the contracted requirements are, no more or no less. The SOW should avoid ambiguity in all cases. If they are worded poorly, the delivered item may not match what you envisioned. This is also where the demo—mentioned previously—comes in handy. If it is documented (e.g., recorded), you can always use language like "per demo" or "as demonstrated in demo" so there is no question how a feature is supposed to work for you.

2. High team availability: Make your team available. Far too many laboratory informatics solution implementations drag on way past what is needed simply because the lab doesn't keep up with the process. While regular daily operations consume a lot of time, and it can be very difficult to allocate extra time for bringing on the new software, it's best to just make the time. The initial energy and impetus of the implementation project—which can take as few as a couple of weeks—disappear surprisingly quickly once delays set in. Interest wanders and a once-great initiative becomes a nagging burden. The single greatest thing you can do to avoid this is allocate the right person(s) to focus on successfully getting the system in place on time and on (or under) budget. That means plenty of communication with the vendor's project manager, executing the training and any configuration tasks your lab is responsible for, and signing off when tasks are complete. You may be surprised how often unsuccessful implementations are actually the fault of the customer.

Implementation details

The implementation itself can be quite simple for a pretty standard system. The minimum scenario would be one to five users, no customization, no configurations beyond standard setup (name the lab's location and any departments, add users, lab logo, address, etc. to report, enter contacts), no interfaces and around two hours of training (online, recorded for reference). And if the solution is cloud-hosted, there is no time (i.e., money) wasted in buying and/or setting up servers, firewalls, etc., so the solution itself can optimistically be in place and running in a day. The rest is up to you; figure something like one to three weeks to go live (a little more if your schedule is tight).

A larger and/or more comprehensive implementation can include several components and be rolled out in phases over one to three months or so. In fact, you can be operational manually for as long as you need to be, bringing instrument interfaces in over time as your budget permits, which allows you to begin using the solution earlier.

All of the phases and their deliverables have price tags associated with them. Your total cost is a function of the license fee or subscription plus the work the vendor performs. The work they do (and the work you do) is what constitutes the implementation and its phases. They can include (in order):

• Project management: The vendor will provide a project manager to coordinate with you and make sure all deliverables are implemented on time and according to the contract. The cost of this is a function of their hours, which begin at the initial meeting (kickoff) and end once your system goes live and all deliverables have been met.

• Kickoff meeting: This is the initial get-together between your project manager and theirs. Review the SOW and the plan to implement it, and clarify resource and time commitments and responsibilities, making sure the schedule works for everybody.

• System installation: If it's to be an onsite installation (discussed later), then your system administrator and the vendor's technical representatives will need to work closely to make sure this is done properly. If the vendor is hosting it for you, the system should be spun up and available for you to log in to within a day or so.

• Gap analysis: This is the identification or verification of the gap between the system as installed and the system as fully functional according to the contract. There should not be any surprises here. If there are (and not good ones), the vendor should rectify them speedily and at no extra charge.

• Work plan (system acceptance test plan): This is the deliverable that spells out essentially what was discussed in the kickoff, with the gap analysis factored in. It's what will be worked towards in order to get to a fully functional, contractually complete system. It should include all tasks, including your verification and sign-off of each deliverable.

• Administrator training: Whether a small and simple setup or something more complex, this is important and integral. Get it online and record it if you can. That way you can refer to it as often as you need to, and also use it to train new administrators.

• Configuration and customization: This is really the bulk portion of implementation. It includes the standard configuration of the solution, plus any extras: instrument interfaces, system/software/agency interfaces, additional custom reports, screen modifications, new fields, etc. (beyond standard setup), adding tests, custom notifications/alerts, web portal configuration, additional training, etc.

• System validation and acceptance: This should be going on throughout the implementation as you sign off on each completed task. Then the final acceptance of the complete system is simply a matter of final overall review and sign-off. A more comprehensive validation involves test scripts for each function, and you will need to go through each, noting pass/fail and any comments. If more work is needed to bring things up to full acceptance level, the vendor (or you, if it was your responsibility) should apply whatever resources necessary to swiftly bring the items to acceptance level.

• User training: Like admin training, user training is essential for a professional, dedicated laboratory informatics system. And in the same ways, online training by job function is the most effective method, enabling recorded sessions to be referred back to by the trainees and used for repeat and additional staff training.

• Go-live support: As with any new informatics system, it is a great contributor to a successful launch if the vendor's support staff are readily available during the initial "go-live" period. This may be a few days, a week or two, or a month, depending on complexity, number of users/samples, etc.

• One year (times X) maintenance and support: This recurring item can be included with your monthly or annual subscription if your solution is a cloud-hosted SaaS one. Otherwise, if you purchase licenses (the vendor may still offer cloud-hosting if you want), then this is a separate annual fee. It's usually wise to include this, at least for the first few years so that updates and upgrades are included, and support hours help your users as they become more comfortable and proficient. Cost usually is around 15-20% of original license fee annually, or bundled into a subscription automatically.

Services

When calculating the overall costs associated with implementing your laboratory informatics solution, don't forget to include calculations of services. No matter how pre-configured the solution may be, any professional laboratory informatics solution will require some amount of standard setup to reflect your particular lab, e.g., lab name and contact details for reports/COA, entering users and their roles/access permissions, adding and/or modifying tests and processes/workflows, renaming some fields, adding/hiding fields, setting up a web portal, interfaces, etc. As mentioned previously, equally indispensable is proper training for both administrators and users. And you may find at any time that you would like additional features or functions. The services here are listed in hourly units. (Again, be very careful if any items that are services-based are listed as fixed-price items.)

Services can include:

• Kickoff meeting: initial planning, identify delta, set schedule, etc.
• Project management
• Setup
• Training (user and admin)
• Additional configurations and/or customization
  • Interfaces
  • Custom screens
  • Custom reports and labels
  • Additional triggers, alerts, etc.
  • Additional or custom functionality
• Validation/Acceptance testing: either to a third-party standard (certification) or to manufacturer claims/specs/contract
• Hosting

Hosting

From the previous list of services, most items have been talked about in some regard, but the hosting of your software deserves a few additional comments. There is strong "service" component that comes with whoever is responsible for hosting your laboratory informatics solution, whether that's you (self-hosted) or some other provider (cloud-hosted).

If you choose to self-host the software, you will have most likely decided to buy the software license rather than rent the solution via a subscription. This is typically the domain of larger businesses that have their own IT department with the knowledge and budget to tackle most of the implementation and much of the maintenance. Even then, there may be times where outside IT help and/or support is required from a consultant or the original software vendor, and this must be calculated into any potential future costs.

If you choose to cloud-host the software, you're either hosting the software on your company's cloud (if they are large enough to have such resources in the first place) or, more likely, you're choosing another company to host the software for you. Regardless of whether its you or another company, several questions emerge about the cloud facilities:

• Does the cloud hosting provider provide purpose-built, reliable and secure cloud hosting infrastructure housed in a state-of-the-art data center that is SSAE 16 SOC 2 certified?
• Are industry standard hardware, software, and configuration practices employed, ensuring first-class performance, security and reliability, with a full 100% uptime guarantee?
• Are global cloud networks employed to provide a seamless global cloud hosting service?
• Can facility meet the special requirements for HIPAA, CLIA, 21 CFR Part 11, or other regulatory compliance data? For example, does it have comprehensive redundancy, failover, data backup and protection (database backups and system-wide backups in secondary location for redundancy), and SSL security and encryption?

Of course, the software can not only be hosted in the cloud but also be served up as a service, typically arranged through the vendor. This SaaS-based approach has its own advantages, as previously discussed.

Maintenance, support, and warranty

The maintenance, support and warranty (MSW) offered by the vendor you choose is almost as important as the laboratory informatics solution itself. The solution is likely to become mission-critical, so having a reliable and responsive team and resources available 24/7 is hugely important in retaining operational and competitive status. Downtime can negatively affect not only immediate customer satisfaction but also your reputation. And professional reputations take a long time and hard work to build, though they can be destroyed swiftly and easily.

As such, when budgeting for a solution, be sure to ask about the company's MSW coverage. Determine what it includes exactly, what it doesn't, and the cost. For example, a purchased LIMS will usually include an MSW as a percentage of the license fee, typically 15-20% annually. It should include some support hours (check how many) so your users can contact the company and get help when they encounter problems, as they are still learning the details and becoming comfortable with the system (that's called support). It should include updates and upgrades (maintenance), and unlimited free fixes of any bugs (warranty).

If the solution is a cloud-hosted, SaaS system, then these are typically rolled in with the annual or monthly subscription (and are typically less costly anyway, since it's easier for the vendor to access and work with the system). Even a purchased, perpetual licensed solution may be available as a cloud-hosted option, and it may be at a lower rate than if you host it yourself (for the same reason). And you have the added bonus of not needing your own servers and IT personnel.

Finally, any provider should warranty (stand behind) all of their work for as long as you are our customer. Any customization work, setup, or configurations they do should also be guaranteed; if they don't work, they should be corrected to perform the way they're supposed to at no additional charge.

Putting it all together

After considering all the above, it's time to put it all together. The importance of an accurate statement of work, as reflected in the sales agreement, can't be understated. Each line item should clearly show exactly what is expected, being as specific as possible, since this will be the entire contractual obligation for both parties. Obviously, the line items may differ from system to system somewhat, according to what features and functions are included by default with the laboratory informatics solution and which, if any, are additional. While the contract SOW is always ultimately an estimate, if careful attention was paid to the above, then it should be quite accurate, and in fact the final cost may even be below the quoted cost if you prioritize your own obligations so that the vendor's hours are used sparingly and efficiently.

The costs can be a mixture of subscriptions (annual and/or monthly), fixed one-time costs (unit of "Each") and/or hourly services. However, the reality is that they really are either license/subscription or services. Any fixed costs for other items are really for services, and represent one of two possible scenarios:

• Final fixed cost: In this case, the cost has been figured by the vendor so as to cover their worst-case hourly labor total. If the item (typically interfaces) is not "worst case," then you are overpaying.
• "Expandable" fixed cost: This is as bad as final fixed cost, and maybe even worse because it's almost a case of "bait-and-switch," popping up as a surprise. The initial "fixed cost" number is low, and additional hourly services are needed to actually deliver the item. This will have been provided for somewhere in the small print. The bottom line is that everything in the solution is really either licensing or hourly services. Just be careful if they are portrayed as anything else.

It is important to be clear which category each line item falls under when figuring costs, which can be divided into 1. up-front (due upon signing), 2. annual, and 3. ongoing (e.g., SaaS subscription). It is useful to clearly lay out each and compute initial costs, as well as first year and subsequent years' costings.

As an example, imagine you're considering a cloud-based SaaS LIMS:

1. Initial: Your initial layout may be as little as your first month's subscription plus the first 40 hours of services, say $500 + $6600 = $7,100. Different vendors have different policies, however, and you may be required to pay for your first full year's subscription and no services, or some other combination. Normally, though, any instrument interface or other services charges aren't due until they are implemented, which may be a few weeks or even a month or so down the road, depending on your budget, complexity of the SOW, and urgency.

2. First year: Your first year's expenses will include everything, including initial license fees, all setup and training, any interfaces and additional configurations or customization, and first annual maintenance, service, and warranty (MSW). (If this isn't included in the SaaS subscription, then it usually commences on full system delivery).

3. Ongoing: Your subscription and MSW will be the only ongoing expenses (included as one in this example), unless you choose to have additional interfaces or other services performed at any time.

Your total laboratory informatics software costs are tallied according to the licenses or subscriptions and hourly services, plus any additional MSW. Two ways to help maximize affordability and success are 1. as stated before, make sure you plan as thoroughly as possible and set aside sufficient funding for the lab operation you envision, and 2. plan out your implementation, perhaps staggering some of the major non-central items to be phased in over time in favor of getting operational with your solution as early as possible.

References

• Abdula, M.; Averdunk, I.; Barcia, R. et al. (2018). The Cloud Adoption Playbook: Proven Strategies for Transforming Your Organization with the Cloud. John Wiley & Sons. pp. 272. ISBN 9781119491859. 

• ASTM Subcommittee E13.15 on Analytical Data (2018). "ASTM E1578-18, Standard Guide for Laboratory Informatics". ASTM International. https://www.astm.org/Standards/E1578.htm. 

• CSols, Inc. (24 January 2019). "How Much Does a LIMS Cost?". Technology Networks. Technology Networks, Ltd. https://www.technologynetworks.com/tn/videos/how-much-does-a-lims-cost-314433. 

• Gordon-Byrne, G. (2014). Buying, Supporting, Maintaining Software and Equipment. CRC Press. pp. 359. ISBN 9781482232790. 

• Hice, R.C. (2016). "Considerations in Purchasing a LIMS" (PDF). Abbott Informatics Corporation. https://www.informatics.abbott/shared/whitepaper-considerations-in-purchasing-a-lims.pdf. 

• Kaldrack, I.; Leeker, M. (2015). There Is No Software, There Are Just Services. Meson Press. pp. 114. ISBN 9783957960566. 

• LabVantage Solutions (28 October 2017). "The True Cost of LIMS". LabVantage Blog. LabVantage Solutions, Inc. https://www.labvantage.com/the-true-cost-of-lims/. 

• Orchard Software (7 November 2018). "Considering a New Laboratory Information System Investment? Read Orchard Software's White Paper Overview of the Total Cost of Ownership for an LIS". Orchard Software Corporation. https://www.orchardsoft.com/blog/considering-a-new-laboratory-information-system-investment-read-orchard-softwares-overview-of-the-total-cost-of-ownership-for-an-lis. 

• Roe, R. (2017). "The Future of Laboratory Informatics" (PDF). Laboratory Informatics Guide 2018. Europa Science Ltd. pp. 12–16. https://www.scientific-computing.com/sites/default/files/content/LIG2018%20web.pdf.