LII:LIMS Selection Guide for ISO/IEC 17025 Laboratories/Choosing laboratory informatics software for better ISO/IEC 17025 compliance
3. Choosing laboratory informatics software for better ISO/IEC 17025 compliance
While ISO/IEC 17025 provides numerous benefits to a laboratory, it still asks a lot of the laboratory in order to conform with the standard.[1] Today, conforming to ISO/IEC 17025 without the help of an information management system is a daunting task, especially given requirements concerning timely data retrieval and security. Labs have increasingly turned to a laboratory information management system (LIMS), not only for helping to modernize and improve the quality of the laboratory but also aiding with compliance to standards like ISO/IEC 17025.[2][3] However, not all LIMS are built the same, and the laboratory must consider LIMS vendors who provide a solution that best helps them limit the burden of ISO/IEC 17025 compliance.
This chapter will focus on a series of considerations the lab manager or group should make towards their informatics purchase, especially in the light of the demands of ISO/IEC 17025, described in the previous chapter. Most aspects of the research and acquisition process are discussed, including specific LIMS functionality that maps to the standard's own requirements for compliance.
3.1 Evaluation and selection
What exactly is a LIMS anyway? Do I need one? What options are available and how do I compare them? What about a request for information (RFI), request for proposal (RFP), or request for quotation (RFQ)? These are questions laboratory professionals typically ponder upon finding themselves charged with the mission of finding software for their ISO/IEC 17025 lab. For many the task can be a daunting proposition.
You may know the regulatory, workflow, and standard-driven needs of your laboratory, but perhaps you don't know much about data management solutions like LIMS—which can better empower your lab to meet those needs—leaving you intimidated by all the options. You'll first need to gauge your lab's informatics needs in order to determine which products are worth investigating further. Of course your lab's analysis requirements, reporting and data sharing constraints, instrument interfacing needs, barcoding and tracking requirements, quality assurance processes, etc. are certainly important factors. But these systems vary in numerous ways, and other important factors exist. Of course, price is one consideration, although value is ultimately more important than a low price. Other important questions that get asked include:
- Should we purchase software licenses or "rent" the software via a subscription-based model?
- Does the software need to be on-site, or is a SaaS hosted option more practical?
- Is a modular or complete system better for us?
- What is the best licensing/rental scheme for us? Should we consider site, named user, concurrent user, or workstation licenses?
- Is the company qualified and trustworthy?
- What functionality is available to help our lab remain compliant with the ISO/IEC 17025 standard?
These and other questions are addressed in this chapter.
3.1.1 Technology considerations
Your laboratory's workflow, instruments, data management requirements, budget, technological expertise, business goals, and risk tolerances will all play a role in deciding what technology to invest in. The ISO/IEC 17025 lab will also be interested in how that technology not only helps with workflow requirements but also better assists the lab with meeting the requirements placed upon them by the standard.
As part of this discovery process, many questions may arise. Chief among them may be how to best match the laboratory's goals with one or more informatics solutions. Does the laboratory envision a small investment and modest goals, taking in a slow but steady flow of analytical requests, or do they envision expansive growth, expanding into multiple testing domains? If the lab is starting small but is confidently expecting to grow, technological investments early on may want to take into account future technologies that may shape data management and security processes. The lab will also want to account for how ISO/IEC 17025 compliance affects future expansion and technology needs.
Second, what kind of work will the lab be doing, and what regulatory responsibilities will guide hardware and software investment at the lab? If your lab will be conducting extractable and leachable testing, you'll be considering chromatography and spectroscopy instruments, as well as requirements for retaining analytical results for regulators. While the ISO/IEC 17025-accredited testing lab will have varying needs for instruments depending on what sort of work they are conducting, its data management system will likely need to be sufficiently robust to meet the needs of the standard. For those labs in more regulated spaces, the system will even need to interface to government systems, or at a minimum report in the regulatory body's specific format. These and other considerations will need to be made. (We'll get more into the functionality requirements of the ISO/IEC 17025 lab in section 3.1.2.)
Third, your laboratory's budget is always important. Does the budget allow for on-site hardware and software systems, with the personnel to maintain them? Is it easier to pay up-front or find a vendor willing to work with you on leasing or rental terms? Is their more value to be had from a slightly more expensive system able to provide the functionality that makes ISO/IEC 17025 compliance more painless for the lab? (We talk about other cost considerations a bit later.)
Finally, will the lab have someone on-site or on-call to resolve technology issues, including set-up and maintenance of software systems? If your lab will have little in the way of available tech help locally, you'll want to consider the distribution model you want to use for any installed software, i.e., you may want to consider software as a service (SaaS). An increasing number of software services are hosted using cloud computing, which when done well is an increasingly reliable option.[4] Having someone else host the software for you typically means the hosting provider will carry a non-trivial portion of responsibility for technology maintenance and security.
Speaking of security, you'll also want to consider the cybersecurity of not only your software solution but also your overall laboratory operations. Does your organization have a cybersecurity plan already in place, or has the decision to make one been postponed? What extra investment is required to ensure your sensitive data is secure? How do your cybersecurity goals compare to the demands of ISO/IEC 17025? (See section 3.1.3 for more on this.) Remember that how you rank your cybersecurity preparedness and implement a cybersecurity plan will also guide your technology investment decisions.[5]
3.1.1.1 Laboratory informatics options
Keeping the above in mind, what are the common software solutions used within an ISO/IEC 17025 laboratory? One of the more commonly discussed options is the LIMS, a laboratory informatics solution designed to assist laboratories with managing testing workflows, data, and other aspects of their operations.
The use of LIMS in ISO/IEC 17025 labs is not a novel concept.[3][6][7][8][9] However, little information can be found as to the percentage of today's ISO/IEC 17025 laboratories using a LIMS in their workflow. A 2017 survey of 30 ISO/IEC 17025-accredited laboratories—18 responding—by the Association of Public Health Laboratories (APHL) found that of the respondents, only 10 (56%) had any spend on a LIMS.[10] This is a tiny pool of all laboratories, so it's likely not all that representative of ISO/IEC 17025-accredited lab use of a LIMS. Yet given:
- the focus on laboratory competence, impartiality, and consistent operations—and by extension, quality—by the ISO/IEC 17025 standard developers; and
- the connection of improving quality through appropriate use of an informatics solutions like a LIMS (see the next subsection)
... it's not difficult to imagine many such labs turning to a LIMS to help them towards quality and compliance goals. In addition, a LIMS or other informatics solution can help eliminate manual processes, improve sample management, increase productivity, and improve regulatory conformance.[11] This, of course, lends to the ISO/IEC 17025 lab's focus on safety, quality, and compliance.
A LIMS can improve laboratory workflows and workloads while enhancing safety, quality, and compliance in a number of ways. A fragmented mix of paper-based and electronic information sources can be a detriment to the traceability of or rapid accessibility to quality control samples, standard operating procedures (SOPs), calibration data, chain of custody data, and other vital aspects of analytical, sampling, and calibration testing in the lab. A well-implemented LIMS can reduce the silos of information and data, while at the same time make that information and data more secure and readily accessible. Given the standard's demands for providing rapid proof of traceable sample movement and relevant quality control data, the LIMS acts as the central integrator and audit trail for that information.[12][13][14] Because the LIMS improves traceability—including through its automated interfaces with instruments and other data systems—real-time monitoring of supply chain issues, quality control data, instrument use, and more is further enabled, particularly when paired with configurable dashboards and alert mechanisms. By extension, labs can more rapidly act on insights gained from those real-time dashboards.[12]
This also means that the lab can react more rapidly to issues that compromise compliance with certification to not only the ISO/IEC 17025 standard but also other requirements by regulatory agencies like the FDA.[3][15][16] Finally, many modern LIMS tailored to ISO/IEC 17025 compliance come pre-configured out of the box with analytical and quality control workflow support tools that can be further optimized to a lab's unique workflow.
However, the LIMS is not the sole information management solution for ISO/IEC 17025 laboratories. Other types of software-based information management solutions are being marketed to laboratories appearing in various industries. Some software vendors have taken to marketing the somewhat related laboratory execution system (LES), which tends to focus more on laboratory test method execution at the process level while integrating other R&D functionalities found in, for example, electronic laboratory notebooks (ELNs).[17][18] Other solutions like the quality management system or QMS may work hand-in-hand with a LIMS to better harmonize the loading and use of workflows and methods in the LIMS, as well as better ensure the lab's risk management principles are enacted and followed.[19] The implication here, of course, is the lab will need to decide on the level of software integration of any other primary or ancillary systems is required for smoother operations, as well as whether or not a system such as a LIMS is able to accommodate.
It's important to note that, in particular, the QMS plays an important role when discussing ISO/IEC 17025. The next subsection will examine the role of the QMS in such laboratories, in relation to quality management and the LIMS.
3.1.1.2 LIMS, quality management, and the QMS
In order to be most successful—while meeting the requirements of standards and regulatory pressures—a laboratory must focus on a culture of quality.[20] A QMS is one means for a laboratory to put additional focus on quality, and ISO/IEC 17025:2017—at least in spirit—promotes the adoption of a QMS. At issue is that while Section 8 of ISO/IEC 17025:2017 addresses the laboratory's management system, it never directly calls it a "quality management system" or QMS; in fact, the word "quality" only appears once in this section. However, the implication is that the standard is addressing quality with its requirements for a management system, i.e., a QMS[21]:
The laboratory shall establish, document, implement, and maintain a management system that is capable of supporting and demonstrating the consistent achievement of the requirements of this document and assuring the quality of the laboratory results.
This discussion about the (quality) management system requirements of ISO/IEC 17025:2017—and the QMS itself—is important in the context of a LIMS, as related discussion of the role of a LIMS in better managing a lab's quality system has been occurring for at least several decades.[22][23] As early as 1999, the "contribution that both system design and functionality" of a LIMS can have on a lab's efforts towards "building quality" was being discussed by researchers.[22] Additionally, as Hull et al. noted in 2011, a LIMS that allows the lab to track and control anything affecting the quality of its operations is critical to successfully developing, implementing, and revising a QMS. "[T]here is more than just the end product or result that needs to be tracked and controlled," the authors add. "All of the intermediate products and resources play a significant role in producing the final product, and each of these needs to be included in the LIMS."[24]
With that, Hull et al.[24], as with their predecessors[22], highlight the importance of practical and consistent LIMS functionality to the efforts of maintaining quality in the lab. As such, with:
- laboratory adoption of ISO/IEC 17025:2017 increasing steadily since 2010, according to the International Laboratory Accreditation Cooperation (ILAC),[25] as a means to demonstrate "that [labs] operate competently and generate valid results"[21] (i.e., focus on quality); and
- LIMS vendors needing to improve their efforts with addressing a lab's need for tracking and controlling quality within its workflow[24]
... today's laboratories seeking to improve quality and meet ISO/IEC 17025 requirements with the help of a LIMS must be mindful of not only what ISO/IEC 17025 demands of the lab, but also what LIMS functionality is required to help the lab be more compliant. A software-based QMS alone won't be as useful as a LIMS or LIMS+QMS combo in managing the requirements of the standard. The next section examines more precisely the functionality required of a LIMS to better manage the necessary compliance, in turn bringing other positive benefits to the lab.
3.1.2 Features and functions for ISO/IEC 17025 compliance
It's clear that a laboratory's quality goals can and should be tied to standards like ISO/IEC 17025[26], and compliance to the standard is better accomplished with the help of a laboratory informatics solution like a LIMS. However, the LIMS needs to have a bit more than generic functionality in order to best assist the lab with its goals.
What follows, in Table 1, is a demonstration of how a modern LIMS requirements specification like LIMSpec ties to the requirements of ISO/IEC 17025. LIMSpec is a robust laboratory informatics requirements specification document that has evolved significantly over the years, and we can turn to LIMSpec to better visualize what the critical requirements of a LIMS are in regards to better complying with ISO/IEC 17025. With the current version of LIMSpec having at its core standards such as ASTM E1578-18 Standard Guide for Laboratory Informatics[27] and ISO/IEC 17025 General requirements for the competence of testing and calibration laboratories[21], the LIMSpec makes for a durable requirements document that, when used to acquire an informatics solution, can better help a laboratory choose appropriate functionality based upon current standards, regulations, guidance, and more.
In particular—rather than looking at the entire LIMSpec, which is described in greater detail later—this section will specifically look at the touch points of ISO/IEC 17025 with LIMSpec and highlight their importance. In addition to Table 1 listing the specific ISO/IEC 17025 section number and the associated LIMSpec requirement, an attempt has been made to explain in clearer terms the impact of the requirement on the lab towards better complying with ISO/IEC 17025.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We can simplify Table 1 down to the following functionality as being important to a lab attempting to conform to ISO/IEC 17025, organized by workflow descriptors:
Test, sample and result management
- Complete capture of a registered sample's data and metadata
- Unique sample identifiers
- Free-form reception-based sample data
- Barcode and RFID support
- Preloaded and configurable sample types and analytical test methods
- Robust sampling and test method development
Quality, security, and compliance
- Multi-level review of test results
- Validation of sampling and test methods
- Support for mapping professional requirements to existing system tasks, sample types, and methods
- Instrument lock-out
- Consistent, retrievable calibration and maintenance records
- Calibration activity linkages
- Calibration and maintenance audit trail
- Nonconformance and deviation tracking
- Statistical trending and control charts
- Internal and external audit management
- Secure backup and retrieval
- Facility monitoring
- Environmental monitoring
- Data retention
- Robust system security
- LIMS validation
- Secure granular access
- Logical and physical access control
Operations management and reporting
- Document management, with versioning and release controls
- Controlled document access
- Provision of the most current document version
- User manuals and training documentation
- Support for unique document identifiers
- Support for training and certification records
- Complaint and problem management
- Unique identification of instruments
- Support for scheduled, frequency-based calibration and maintenance
- Support for data and metadata archiving
- Support for rapid and accurate retrieval of archived data and metadata
- Support for certificates of analysis or similar verification documents
- Support for changed, amended, or re-issued reports
3.1.3 Cybersecurity considerations
From law firms[30] to automotive manufacturers[31], the need to address cybersecurity is increasingly apparent. In 2018, the Center for Strategic & International Studies estimated that cybercrime causes close to $600 billion in damages to the global economy every year[32], though due to underreporting of crimes, that number may be much higher. That number also likely doesn't take into account lost business, fines, litigation, and intangible losses[33] In the end, businesses of all sizes average about $200,000 in losses due to a cybersecurity incident[34], and nearly 60 percent of small and midsize businesses go bankrupt within six months because of it.[35]
ISO/IEC 17025 laboratories are no exception, regardless of business size. Even tiny labs whose primary digital footprint is a WordPress website advertising their lab are at risk, as hackers could still spread malware, steal user data, add the website to a bot network, hack the site for the learning experience, or even hack it just for fun.[36][37][38] Even more importantly are those labs performing digital data management tasks that handle sensitive proprietary manufacturer data, requiring additional cybersecurity considerations.
ISO/IEC 17025:2017 doesn't use the word "cybersecurity," but it does address the proper control of data, in its section 7.11. In particular, section 7.11.3 and 7.11.4 make it clear that the LIMS should be protected, whether hosted locally or hosted, in the cloud, by a third-party provider.[21] Importantly, the standard notes that the LIMS should have sufficient mechanism to protect its contents from unauthorized access, as well as from tampering and unexpected loss. It adds that the LIMS should "be maintained in a manner that ensures the integrity of the data and information" and promptly record any nonconformance or breaches of security, as well as any corrective actions taken.[21] These are most certainly cybersecurity concerns, which must be properly addressed by the ISO/IEC 17025 lab.
Laboratories attempting to conform to ISO/IEC 17025 can integrate cybersecurity thinking into its laboratory informatics product selection in several ways. First, the organization should have a cybersecurity plan in place, or if not, it should be on the radar. This is a good resource to tap into in regards to deciding what cybersecurity considerations should be made for the software. Can the software help your organization meet your cybersecurity goals? What regulatory requirements for your lab are or are not covered by the software?[5] Another tool to consider—which may have been used in any prior cybersecurity planning efforts—is a cybersecurity framework. Many, but not all, cybersecurity frameworks include a catalog of security controls. Each control is "a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements."[39] These controls give the implementing organization a concrete set of configurable goals to apply to their overall cybersecurity strategy. Other frameworks may be less oriented to security controls and more program-based or risk-based. Choosing the best frameworks will likely depend on multiple factors, including the organization's industry type, the amount of technical expertise within the organization, the budget, the organizational goals, the amount of buy-in from key organizational stakeholders, and those stakeholders' preferred approach.[5]
Finally, having an organizational cybersecurity plan that incorporates one or more cybersecurity frameworks gives the laboratory ample opportunity to apply stated goals and chosen security controls to the evaluation and selection process for its informatics software. In particular, a user requirements specification (URS) that incorporates cybersecurity considerations will certainly help a laboratory with meeting regulatory requirements while also protecting its data systems. A USR that is pre-built with cybersecurity controls in mind—such as LIMSpec, discussed later—makes the evaluation process even easier.
3.1.4 Regulatory compliance considerations
Consider approaching the question of regulatory compliance from the standpoint of adopting standards, in this case ISO/IEC 17025. Consider first that the risks and consequences of performing a task poorly drives regulation and, more preferably[40][41], standardization, which in turn moves the "goalposts" of quality and security among organizations. In the case of regulations, those organization that get caught not conforming to the necessary regulations tend to suffer negative consequences, providing some incentive for them to improve organizational processes and procedures.
One of the downsides of regulations is that they can at times be "imprecise" or "disconnected"[41] from what actually occurs within the organization and its information systems. Rather than focusing heavily on regulatory conformance, well-designed standards may, when adopted, provide a clearer path of opportunity for organizations to improve their operational culture and outcomes, particularly since standards are usually developed with a broader consensus of interested individuals with expertise in a given field.[40] In turn, the organizations that adopt well-designed standards like ISO/IEC 17025 likely have a better chance of conforming to the regulations they must, and they'll likely have more interest in maintaining and improving the goalposts of quality and security in the lab.
Additionally, reputable software developers of laboratory informatics software will not only adopt their own industry standards for software development but also understand how the ISO/IEC 17025 and LIMS requirements intersect. In turn, the developed software should meet regulations and standards, help the laboratory comply with its regulations and standards, and be of reliably good quality.
If you're a potential buyer of a laboratory informatics solution, it may be that you know a bit about your laboratory's workflow and have at least a remedial understanding of how ISO/IEC 17025 influences how that workflow is conducted, but you're not entirely informed about all the details of how a LIMS can help your lab better conform to the standard, along with other regulations and standards. Turning to a URS such as LIMSpec—which was developed around laboratory regulations and standards, including ISO/IEC 17025—and reviewing the various statements contained within may be necessary to help further inform you. Additionally, as you investigate various informatics options, you can then use the requirements in the URS as a base for your laboratory's own requirements list. Using the categories and their subdivisions, you can then add those requirements that are unique to your laboratory and industry that are not sufficiently covered by the base URS. As you review the various options available to you and narrow down your search, your own list of requirements can be used as both as a personal checklist and as a requirements list you hand over to the vendor you query. And since your URS is based off the standards and regulations affecting your lab, you can feel more confident in your acquisition and its integration into your laboratory workflow.
3.1.5 System flexibility
Before selecting a solution, your laboratory should also have internal discussions about how diversified its offered services are, as well as what the future may bring to the lab. If, for example, your lab is currently configured for one type of testing, does your existing laboratory informatics system—or the ones you may be considering—have the flexibility to add other types of testing, protocols, and workflows? Will you be doing the footwork to add them, or will the vendor of your system support you in that effort? If you're a start-up, will your lab be focusing solely on a specific type of testing and expand into other types of analytical work later, or will your test menu need to be much broader right from the start? In most of these cases, you'll desire a LIMS that is flexible enough to allow for not only running the specific tests you need now, but also sufficiently expandable for any future testing services your lab may conduct in the mid- and long-term. Having the ability to create and customize sample registration screens, test protocols, labels, reports, specification limit sets, measurement units, and substrates/matrices while being able to interface with practically most any instrument and software system required will go a long way towards making your expanding test menu and workflows integrates as smoothly as possible.
Such a system will typically be marketed as being highly user-configurable, giving labs a relatively painless means to adapt to rapid changes in test volume and type over time. However, once you've internally addressed current and anticipated future growth, your lab will want to learn what explicitly makes any given vendor's system user-configurable. How easy is it to configure the system to new tests? Add custom reports? What knowledge or skills will be required of your lab in order to make the necessary changes, i.e., will your staff require programming skills, or are the administrator and advanced user functions robust enough to make changes without hard-coding? These and other such questions should be fully addressed by the vendor in order to set your mind at ease towards a system's stated flexibility. Ultimately, you want the system to be flexible enough to change with the laboratory—and industry—itself, while minimizing overall costs and reducing the time required to make any necessary modifications.
3.1.6 Cost considerations
First, you'll want to be clear on what will be included in the sales agreement. Whether through an estimate or statement of work (SOW), it is important it includes exactly what is expected, being as specific as possible, since this will be the entire contractual obligation for both you the buyer and them the vendor. Note that line items may differ slightly from system to system, according to what features and functions are included by default with each vendor's solution and which, if any, are additional. Also keep in mind that any hourly amount in the the estimate or SOW is usually a best estimate; however, if sufficient attention to detailed requirements has been given, 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 estimate or SOW should optimally include:
- licensing or subscription rates;
- required core items to meet federal, state, and local regulations;
- additional optional items and totals; and
- required services (implementation, maintenance and support, optional add-ons).
There are two primary ways to price a laboratory informatics solution: a one-time license fee or a subscription rate (cloud-hosted SaaS). If you have your own dedicated IT department and staff, you may prefer the former (although many system administrators are just as happy to let it be hosted elsewhere rather than add to their workload). Otherwise, a SaaS subscription may well be the better and more cost-effective way to go (since the primary IT cost is simply internet access). This item will be part of your up-front cost and, in the case of subscription, it will also figure into your first year and ongoing costs; otherwise only associated maintenance, support, and warranty (MSW) will figure in. Typically, your first year's subscription costs will be due at signing. 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 costs and annual MSW) than paying for a license fee.
In addition to the two types of software pricing, there are also sub-types. Generally these are based on the number of users (or, in some cases, "nodes," which are simply any entities that access the informatics system, including other systems, instruments, etc.). How these are counted can vary.
- Named users: This method bases pricing on the actual individual users of the system, even if they only log in sporadically. Users may not use each other's logins (this is a no-no regardless of pricing structure, for good laboratory practice and other regulatory reasons).
- Concurrent users: This 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 or 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.
- Unlimited users: In the case of very large labs (typically 30 to 50 and up), the license or subscription may simply be a flat fee that allows any number of users.
The line items in the estimate or SOW should reflect these nuances, as well as whether the listed costs are monthly or annual (for subscription services), hourly (typically for support and training), or a fixed one-time cost. Additionally, be cautious with fixed costs, as they typically 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 a line item (e.g., an interface) 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 a laboratory informatics 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: up-front (due upon signing), annual, or 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. For example, your initial obligation may be as little as your first year's subscription plus the first 40 hours of services. Different vendors have different policies, however, and you may be required to pay for your first full year's subscription and all services, or some other combination. Normally, though, any instrument interface or other service charges aren't due until the they are implemented, which may be a few weeks or even a month down the road. This may depend on your budget, complexity of the SOW, and urgency. 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 MSW. (If this isn't included in the SaaS subscription, then it usually commences on full system delivery). Afterwards, 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.
3.2 Implementation
If you've ever worked through a system implementation process with a vendor, it was hopefully a smooth process. However, there are plenty of horror stories out there, highlighting the need of the laboratory to discuss in detail how a potential vendor will handle installation, validation, and training for the informatics solution. Does the vendor truly understand the industry and your needs? Does the vendor assign a project manager who will work with you, from planning to go-live and beyond? Can they offer you references of other labs who have gone through implementation so you can compare notes with those labs? How much attention does the potential vendor give to related issues such as data integrity of migrated data? Do they have the means to properly handle your legacy data? And are they able to work with your schedule, even if it means implementing software at off-peak work hours?[42][43]
As you finally get down to the ultimate decision on which vendor to work with, you may wish to start setting up an implementation checklist as part of your early project planning. Do you receive a help desk account as part of the implementation process, and if so, what information is included? If not, you'll need to keep track of specific details such as business associate agreement (BAA), sales agreement, scope documents, welcome letters, documentation, and approved staff who can utilize the vendor's support. You'll likely need to share other configuration details with the vendor, including time zone requirements, DNS and URL requirements, up-time monitors, and administrative account requirements. Finally, you'll want to ensure you and the vendor are on the same page concerning any additional customization, integration, and system validation requirements, ensuring the roll-out period is pain-free and efficient.
3.2.1 Internal and external integrations
Laboratories acquire data management software for many reasons, including improving accuracy and quality, saving time, increasing productivity, and adding capabilities. One way of doing all of those activities is to integrate or interface your systems, databases, and instruments so that human error is greatly reduced or eliminated, workflows are automated and sped up, and each component's capabilities are brought into play in the most efficient and effective ways possible. As such, you'll want to inquire with the vendor about its solution's hardware and software integration capabilities. Is it designed to interface with every laboratory instrument or software that can output any readable electronic file? Or are integrations limited to certain instruments and systems? How does it connect, i.e., what protocols does the software depend on to connect with other systems? Does the system allow a user to map their own file imports and exports? Can system processes be set to detect new instances of file outputs at regular intervals? Ask these and other questions to make sure the vendor clearly describes what internal and external integrations are supported with their application.
In many cases, a vendor's LIMS solution will have instrument integration capability built into the software, but occasionally such interfaces are separate from the main software. Today's instrument interfaces are generally built on standardized communication protocols such as RS-232, RS-422, IEEE-488 (GPIB), USB, Ethernet, and more.[44] The LIMS that can support such instrument integrations is increasingly vital to the ISO/IEC 17025 laboratory. Such labs may also want their laboratory informatics solution to be able to communicate with other software and databases. This is often done using application programming interfaces (APIs) that depend on web services implementation protocols such as REST and SOAP.[45][46][47] These messaging protocols actually allow for the creation of an API that receives communication requests and sends responses between two software systems. A more practical example is wanting your laboratory informatics solution to communicate with an enterprise resource planning (ERP) application or a QMS. Perhaps rather than housing quality management documents exclusively in the LIMS, the lab has had a dedicated electronic QMS for years, and they'd like to be able to interface that with the LIMS. APIs and communication protocols make this happen.[46]
3.3 MSW, updates, and other contracted services
_-_The_Noun_Project.svg)
The MSW offered with the vendor's solution is almost as important as the solution itself. The laboratory informatics solution you acquire is more than than the software you operate: it's mission-critical and deserves having a reliable and responsive team with the necessary resources to ensure it remains operational. Downtime can negatively affect both immediate customer satisfaction and your reputation. As such, it's imperative you ask the vendor about the details of its MSW, making sure you understand what is and isn't covered, as well as how much it will cost. Cost-wise, industry norms are anywhere from 15% to 25% of either the license fee or total contract, levied annually to provide this coverage.[48] Alternatively, it may simply be included with your subscription. The MSW will include a specified number of support and maintenance hours or guarantees. The actual warranty should be unlimited for as long as the MSW or subscription is kept current.
Maintenance includes any and all work necessary to keep your system working as designed. It should include updates, patches, or fixes, and most if not all upgrades. (Note, however, a major upgrade to a totally new edition may not be covered, but it may come at a negotiable, significantly lower cost.[49]) The support aspect of MSW generally consists of a specified number of hours dedicated more to helping you with the operation of the system rather than "fixing" anything. Support includes guidance on training, password or login support, and more. Finally, with any professional application you also expect to have a warranty. The warranty should cover anything that doesn't work that otherwise should for the designated period of time.[49] That includes any standard features and functions, as well as any additional ones that were delivered and signed off on, and any other work performed by the vendor or its representatives. However, a typical warranty does not cover anything that was working fine, but upon being manipulated in a way beyond normal operation the functionality ceased. In these cases, you'll probably have to pay to get it fixed.
Beyond the MSW, additional updates and services related to the system may also be required. No matter how well it is pre-configured, any professional laboratory informatics solution will require some amount of standard setup to reflect your particular lab. This includes adding lab branding and demographics for reports and certificates; entering users, their roles, and access permissions; adding and/or modifying tests and workflows; renaming fields; adding or hiding fields; setting up a web portal; and implementing interfaces. Equally indispensable is proper training for both users and administrators. And of course you may later find that you would like additional features or functions. These and other services may prove particularly useful to the laboratory with little in the way of IT and systems expertise. As such, the vendor may provide one or more of the following as a billable service for the laboratory:
- initial implementation meeting (e.g., initial planning, identify delta, set schedule)
- project management
- requirements gathering and documentation
- initial setup
- user and administrator training
- configuration and customization
- interface development and implementation
- custom screen and field development
- custom functionality development
- custom reports and labels
- custom triggers and alerts
- validation or acceptance testing (to a third-party standard or certification, or to agreed manufacturer specs)
3.4 How a user requirements specification fits into the entire process (LIMSpec)
Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something."[50] In other words, an existing or theoretical product, concept, or idea is presented in detail for a particular audience. In a broad sense, detailing the specifics about a project, concept, or idea to others is just common sense. This applies just as well to the world of software development, where a software requirements specification is essential for preventing the second most commonly cited reason for project failure: poor requirements management.[51]
In fact, the ISO/IEC/IEEE 29148:2018 standard (a conglomeration of what was formerly IEEE 830 and other standards) is in place to help specify "the required processes implemented in the engineering activities that result in requirements for systems and software products" and provide guidelines for how to apply those requirements.[52] The standard describes the characteristics that make up quality software requirement development, including aspects such as[53]:
- correctly describing system behavior;
- effectively removing ambiguity from the language used;
- completely covering the system behavior and features;
- accurately prioritizing and ranking the requirements; and
- unequivocally ensuring the requirements are testable, modifiable, and traceable.
A requirement typically comes in the form of a statement that begins with "the system/user/vendor shall/should ..." and focuses on a provided service, reaction to input, or expected behavior in a given situation. The statement may be abstract (high-level) or specific and detailed to a precise function. The statement may also be of a functional nature, describing functionality or services in detail, or of a non-functional nature, describing the constraints of a given functionality or service and how it's rendered. An example of a functional software requirement could be "the user shall be able to query either all of the initial set of databases or select a subset from it." This statement describes specific functionality the system should have. On the other hand, a non-functional requirement, for example, may state "the system's query tool shall conform to the ABC 123-2014 standard." The statement describes a constraint placed upon the system's query functionality. (You've already seen other examples of this in section 3.1.2.)
This is where a requirements specification shines, not only for the software developer but also for those acquiring the software. A set of development requirements, compiled in the form of a software requirements specification, can serve to strengthen the software development process. For those acquiring the software, a set of user requirements, compiled in the form of a URS, can be used for the selection and acquisition of software or a service.[54][55] In the case of the URS, the acquiring business can approach this several ways. The simple way would be to essentially take the vendor at the word in regards to what they say their system can and can't do, agreeing formally to their description and taking responsibility that it will cover all the applicable regulations required by your business. However, this method isn't comprehensive and leaves the business open to not being able to fully meet its goals.[55]
The other method has the URS be specific to your business' needs. The process is more work but leaves less to chance.[55] Developing your own URS isn't always straightforward. Often times, the developed document turns into a mix of "wishlist" requirements from potential and active clients, as well as regulation-mandated requirements. The wishlist items aren't necessarily ignored by developers, but the URS should in fact clearly prioritize requirements as "nice to have" or "essential to system operation," or something in between.[56][57][58] Whatever the URS looks like in the end, it's ultimately up to the vendor to be able to demonstrate how the software does and does not meet its requirements.
As mentioned earlier in this chapter, the requirements of ISO/IEC 17025 can be directly mapped to a robust URS such as LIMSpec, an evolving set of software requirements specifications for laboratory informatics systems. In Chapter 5, we will demonstrate how a URS like LIMSpec can be put to use to best ensure your lab acquires a LIMS that best supports your lab's compliance efforts. But first, in the the next chapter, we provide some resources to help you make more informed decisions about your LIMS acquisition.
References
- ↑ Douglas, S.E. (January 2023). "LIMS Q&A:How does ISO/IEC 17025 impact laboratories?". LIMSwiki. https://www.limswiki.org/index.php/LIMS_Q&A:How_does_ISO/IEC_17025_impact_laboratories?. Retrieved 11 February 2023.
- ↑ Boyar, Kyle; Pham, Andrew; Swantek, Shannon; Ward, Gary; Herman, Gary (2021), Opie, Shaun R., ed., "Laboratory Information Management Systems (LIMS)" (in en), Cannabis Laboratory Fundamentals (Cham: Springer International Publishing): 131–151, doi:10.1007/978-3-030-62716-4_7, ISBN 978-3-030-62715-7, http://link.springer.com/10.1007/978-3-030-62716-4_7. Retrieved 11 February 2023
- ↑ 3.0 3.1 3.2 Apte, A. (20 October 2020). "Is Your Food Testing Lab Prepping for an ISO/IEC 17025 Audit?". Food Safety Tech. https://foodsafetytech.com/column/is-your-food-testing-lab-prepping-for-an-iso-iec-17025-audit/. Retrieved 11 February 2023.
- ↑ Izrailevsky, Y.; Bell, C. (2018). "Cloud Reliability". IEEE Cloud Computing 5 (3): 39–44. doi:10.1109/MCC.2018.032591615.
- ↑ 5.0 5.1 5.2 Douglas, S.E. (July 2020). "Comprehensive Guide to Developing and Implementing a Cybersecurity Plan". LIMSwiki.
- ↑ Colangeli, Patrizia; Ferrilli, Monica; Quaranta, Fabrizio; Malizia, Elio; Mbulu, Rosa-Stella; Mukete, Esther; Iipumbu, Lukas; Kamhulu, Anna et al. (2012). "Laboratory information management system: an example of international cooperation in Namibia". Veterinaria Italiana 48 (3): 241–251. ISSN 1828-1427. PMID 23038071. https://pubmed.ncbi.nlm.nih.gov/23038071.
- ↑ Xueken, C. (2012). "Application and Research of LIMS for the Traceability of a Testing Laboratory (LIMS针对检测实验室检测可溯源性的应用与研究)". Microcomputer Applications 2012 (8): 47–50. http://www.cqvip.com/qk/96101x/20128/43050128.html.
- ↑ Thurston, C. (August 2013). "World’s largest GTL facility turns to LIMS for enhanced operations". Hydrocarbon Processing (Gulf Publishing Company, LLC). https://www.hydrocarbonprocessing.com/magazine/2013/august-2013/bonus-report-lng-developments/world-s-largest-gtl-facility-turns-to-lims-for-enhanced-operations.
- ↑ Taina, Alina (1 May 2015). "Software validation with respect to requirements specified by SR EN 15189:2013 and SR EN 17025:2005. A practical approach for a medical laboratory information management system (LIMS) and a gas meter in testing laboratory". 2015 9th International Symposium on Advanced Topics in Electrical Engineering (ATEE) (Bucharest, Romania: IEEE): 720–724. doi:10.1109/ATEE.2015.7133899. ISBN 978-1-4799-7514-3. http://ieeexplore.ieee.org/document/7133899/.
- ↑ Association of Public Health Laboratories (February 2018). "Laboratory Costs of ISO/IEC 17025 Accreditation: A 2017 Survey Report" (PDF). https://www.aphl.org/aboutAPHL/publications/Documents/FS-2018Feb-ISO-IEC-Accreditation-Costs-Survey-Report.pdf. Retrieved 11 February 2023.
- ↑ "Astrix 2020 LIMS Market Research Survey Report" (PDF). Astrix Technology, LLC. March 2021. https://astrixinc.com/wp-content/uploads/2021/03/Astrix-2020-LIMS-Market-Research-Report.pdf. Retrieved 11 February 2023.
- ↑ 12.0 12.1 Smith, K. (2 July 2019). "Integrated Informatics: Optimizing Food Quality and Safety by Building Regulatory Compliance into the Supply Chain". Food Safety Tech. https://foodsafetytech.com/feature_article/integrated-informatics-optimizing-food-quality-and-safety-by-building-regulatory-compliance-into-the-supply-chain/. Retrieved 11 February 2023.
- ↑ McDermott, P. (31 July 2018). "How Digital Solutions Support Supply Chain Transparency and Traceability". Food Safety Tech. https://foodsafetytech.com/column/how-digital-solutions-support-supply-chain-transparency-and-traceability/. Retrieved 11 February 2023.
- ↑ Evans, K. (15 November 2019). "The Digital Transformation of Global Food Security". Food Safety Tech. https://foodsafetytech.com/feature_article/the-digital-transformation-of-global-food-security/. Retrieved 11 February 2023.
- ↑ Paszko, C. (26 October 2015). "How LIMS Facilitates ISO 17025 Certification in Food Testing Labs". Food Safety Tech. https://foodsafetytech.com/feature_article/how-lims-facilitates-iso-17025-certification-in-food-testing-labs/. Retrieved 11 February 2023.
- ↑ Daniels, T. (22 March 2017). "Using LIMS to Get In Shape for FDA’s Visit". Food Safety Tech. https://foodsafetytech.com/column/using-lims-get-shape-fdas-visit/. Retrieved 11 February 2023.
- ↑ "iLES Food & Beverages Lab Execution". iVention BV. https://hs.iles.cloud/en/food-and-beverages-lab-execution. Retrieved 11 February 2023.
- ↑ LabVantage Solutions (16 April 2020). "How LIMS can Improve your Food and Beverage Testing Lab". News Medical. https://www.news-medical.net/whitepaper/20200416/How-LIMS-can-Improve-your-Food-and-Beverage-Testing-Lab.aspx. Retrieved 11 February 2023.
- ↑ Famili, Parsa; Cleary, Susan (9 March 2022), Huynh‐Ba, Kim, ed., "Laboratory Information Management System (LIMS) and Electronic Data" (in en), Analytical Testing for the Pharmaceutical GMP Laboratory (Wiley): 345–373, doi:10.1002/9781119680475.ch10, ISBN 978-1-119-12091-9, https://onlinelibrary.wiley.com/doi/10.1002/9781119680475.ch10. Retrieved 11 February 2023
- ↑ Kennedy, T.M.; Kennedy, J.L.; Donaldson, R.M. et al. (2022). "A Call for Action to Maintain a Culture of Quality in the Clinical Laboratory" (PDF). Genetics & Molecular Medicine 4 (1): 1–2. doi:10.33425/2689-1077.1013. https://www.scivisionpub.com/pdfs/a-call-for-action-to-maintain-a-culture-of-quality-in-the-clinical-laboratory-2116.pdf.
- ↑ 21.0 21.1 21.2 21.3 21.4 "ISO/IEC 17025:2017 General requirements for the competence of testing and calibration laboratories". International Organization for Standardization. November 2017. https://www.iso.org/standard/66912.html. Retrieved 11 February 2023.
- ↑ 22.0 22.1 22.2 Steele, T. W.; Laugier, Alain; Falco, François (3 March 1999). "The impact of LIMS design and functionality on laboratory quality achievements". Accreditation and Quality Assurance 4 (3): 102–106. doi:10.1007/s007690050324. ISSN 0949-1775. http://link.springer.com/10.1007/s007690050324.
- ↑ Çağındı, Özlem; Ötleş, Semih (1 December 2004). "Importance of laboratory information management systems (LIMS) software for food processing factories" (in en). Journal of Food Engineering 65 (4): 565–568. doi:10.1016/j.jfoodeng.2004.02.021. https://linkinghub.elsevier.com/retrieve/pii/S0260877404000846.
- ↑ 24.0 24.1 24.2 Hull, Carl; Wray, Bruce; Winslow, Ford; Vilicich, Mark (1 November 2011). "Tracking and Controlling Everything that Affects Quality is the Key to a Quality Management System" (in en). Combinatorial Chemistry & High Throughput Screening 14 (9): 772–780. doi:10.2174/138620711796957125. http://www.eurekaselect.com/openurl/content.php?genre=article&issn=1386-2073&volume=14&issue=9&spage=772.
- ↑ "About ILAC > Facts & Figures". ILAC. 2021. https://ilac.org/about-ilac/facts-and-figures/. Retrieved 11 February 2023.
- ↑ Douglas, S.E. (January 2023). "LIMS Q&A:What is the importance of ISO/IEC 17025 to society?". LIMSwiki. https://www.limswiki.org/index.php/LIMS_Q&A:What_is_the_importance_of_ISO/IEC_17025_to_society?. Retrieved 11 February 2023.
- ↑ "ASTM E1578-18 Standard Guide for Laboratory Informatics". ASTM International. 23 August 2019. https://www.astm.org/e1578-18.html. Retrieved 11 February 2023.
- ↑ Sanchez, Juan M. (11 May 2021). "Use of Control Charts and Scientific Critical Thinking in Experimental Laboratory Courses: How They Help Students to Detect and Solve Systematic Errors" (in en). Journal of Chemical Education 98 (5): 1822–1828. doi:10.1021/acs.jchemed.0c00885. ISSN 0021-9584. https://pubs.acs.org/doi/10.1021/acs.jchemed.0c00885.
- ↑ Maxwell, G. (1 November 2003). "Using Workflows in LIMS to Reduce Customization". Scientific Computing. Archived from the original on 07 August 2009. https://web.archive.org/web/20090807034051/http://www.scientificcomputing.com/using-workflows-in-lims-to-reduce.aspx. Retrieved 11 February 2023.
- ↑ Sobowale, J. (1 March 2017). "Law firms must manage cybersecurity risks". ABA Journal. American Bar Association. http://www.abajournal.com/magazine/article/managing_cybersecurity_risk/. Retrieved 11 February 2023.
- ↑ Watney, C.; Draffin, C. (November 2017). "Addressing new challenges in automotive cybersecurity" (PDF). R Street Policy Study No. 118. R Street Institute. https://www.rstreet.org/wp-content/uploads/2018/04/118-1.pdf. Retrieved 11 February 2023.
- ↑ Lewis, J.A. (21 February 2018). "Economic Impact of Cybercrime". Center for Strategic & International Studies. https://www.csis.org/analysis/economic-impact-cybercrime. Retrieved 11 February 2023.
- ↑ "BLOG: Cost of Cyber Crime to Small Businesses". Virginia SBDC Blog. Virginia SBDC. 30 May 2017. Archived from the original on 05 July 2020. https://web.archive.org/web/20200705061737/https://www.virginiasbdc.org/blog-cost-of-cyber-crime-to-small-businesses/. Retrieved 11 February 2023.
- ↑ "Hiscox Cyber Readiness Report 2019" (PDF). Hiscox Ltd. April 2019. https://www.hiscox.com/documents/2019-Hiscox-Cyber-Readiness-Report.pdf. Retrieved 11 February 2023.
- ↑ Galvin, J. (7 May 2018). "60 Percent of Small Businesses Fold Within 6 Months of a Cyber Attack. Here's How to Protect Yourself". Inc.com. https://www.inc.com/joe-galvin/60-percent-of-small-businesses-fold-within-6-months-of-a-cyber-attack-heres-how-to-protect-yourself.html. Retrieved 11 February 2023.
- ↑ Grima, M. (15 June 2022). "Top reasons why WordPress websites get hacked (and how you can stop it)". WP White Security. https://www.wpwhitesecurity.com/why-malicious-hacker-target-wordpress/. Retrieved 11 February 2023.
- ↑ Moen, D. (19 April 2016). "What Hackers Do With Compromised WordPress Sites". Wordfence Blog. Defiant, Inc. https://www.wordfence.com/blog/2016/04/hackers-compromised-wordpress-sites/. Retrieved 11 February 2023.
- ↑ Talaleve, A. (22 February 2022). "Website Hacking Statistics You Should Know in 2022". Patchstack. https://patchstack.com/articles/website-hacking-statistics/. Retrieved 11 February 2023.
- ↑ "security control". Computer Security Resource Center. National Institute of Standards and Technology. 2019. https://csrc.nist.gov/glossary/term/security_control. Retrieved 11 February 2023.
- ↑ 40.0 40.1 Ciocoui, C.N.; Dobrea, R.C. (2010). "Chapter 1. The Role of Standardization in Improving the Effectiveness of Integrated Risk Management". In Nota, G.. Advances in Risk Management. IntechOpen. doi:10.5772/9893. ISBN 9789535159469.
- ↑ 41.0 41.1 "Data Standardization: A Call to Action" (PDF). JPMorgan Chase & Co. May 2018. https://www.jpmorganchase.com/content/dam/jpmc/jpmorgan-chase-and-co/documents/call-to-action.pdf. Retrieved 11 February 2023.
- ↑ Wagner, M. (10 October 2019). "7 Software Implementation Challenges and How to Solve Them". WalkMe Blog. WalkMe Ltd. https://blog.walkme.com/7-software-implementation-challenges/. Retrieved 11 February 2023.
- ↑ Mura, A. (12 July 2018). "Bullet-Proof Software Implementation Plan: Challenges and Tactics". Userlane Digital Adoption Blog. Userlane GmbH. https://www.userlane.com/software-implementation-plan/. Retrieved 11 February 2023.
- ↑ Williams, C.D.H.. "Computer Interfaces for Instrumentation Systems". University of Exeter. https://newton.ex.ac.uk/teaching/CDHW/Interfaces/. Retrieved 11 February 2023.
- ↑ Monus, A. (17 October 2022). "SOAP vs REST vs JSON - a 2023 comparison". Raygun. https://raygun.com/blog/soap-vs-rest-vs-json/. Retrieved 11 February 2023.
- ↑ 46.0 46.1 LabVantage Solutions (7 January 2018). "A Quick Guide to LIMS Web Services". LabVantage Solutions, Inc. https://www.labvantage.com/a-quick-guide-to-lims-web-services/. Retrieved 11 February 2023.
- ↑ Grand, A.; Geda, E.; Mignone, A. et al. (2019). "One tool to find them all: A case of data integration and querying in a distributed LIMS platform". Database 2019: baz004. doi:10.1093/database/baz004.
- ↑ Scavo, F. (8 February 2005). "High Software Maintenance Fees and What to Do About Them". Computer Economics. https://www.computereconomics.com/article.cfm?id=1033. Retrieved 11 February 2023.
- ↑ 49.0 49.1 Gordon-Byrne, G. (2014). "Maintenance in the Digital World". IT Performance Improvement. Taylor & Francis, LLC. Archived from the original on 05 May 2021. https://web.archive.org/web/20210505220938/http://www.ittoday.info/ITPerformanceImprovement/Articles/2014-08GordonByrne2.html. Retrieved 11 February 2023.
- ↑ "specification". Merriam-Webster. Merriam-Webster, Inc. https://www.merriam-webster.com/dictionary/specification. Retrieved 11 February 2023.
- ↑ Bieg, D.P. (August 2014). "Introduction" (PDF). Requirements Management: A Core Competency for Project and Program Success. Project Management Institute. p. 3. https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf. Retrieved 11 February 2023.
- ↑ "ISO/IEC/IEEE 29148:2018". International Organization for Standardization. November 2018. https://www.iso.org/standard/72089.html. Retrieved 11 February 2023.
- ↑ Seibert, P. (28 July 2011). "How do you write software requirements? What are software requirements? What is a software requirement?". HubTechInsider. https://hubtechinsider.wordpress.com/2011/07/28/how-do-you-write-software-requirements-what-are-software-requirements-what-is-a-software-requirement/. Retrieved 11 February 2023.
- ↑ Memon, A. (Spring 2010). "Software Requirements: Descriptions and specifications of a system" (PDF). University of Maryland. https://www.cs.umd.edu/~atif/Teaching/Spring2010/Slides/3.pdf. Retrieved 11 February 2023.
- ↑ 55.0 55.1 55.2 Schmitt, S. (2018). "User Requirements Specifications–How Difficult Can It Be?". Pharmaceutical Technology 42 (11): 58. https://www.pharmtech.com/view/user-requirements-specifications-how-difficult-can-it-be-0. Retrieved 11 February 2023.
- ↑ Aasem, M.; Ramzan, M.; Jaffar, A. (2010). "Analysis and optimization of software requirements prioritization techniques". Proceedings from the 2010 International Conference on Information and Emerging Technologies: 1–6. doi:10.1109/ICIET.2010.5625687.
- ↑ Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. https://www.phase2technology.com/blog/successful-requirements-gathering. Retrieved 11 February 2023.
- ↑ Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. Archived from the original on 25 September 2019. https://web.archive.org/web/20190925003040/http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 11 February 2023.
Citation information for this chapter
Chapter: 3. Choosing laboratory informatics software for better ISO/IEC 17025 compliance
Title: LIMS Selection Guide for ISO/IEC 17025 Laboratories
Edition: First Edition
Author for citation: Shawn E. Douglas
License for content: Creative Commons Attribution-ShareAlike 4.0 International
Publication date: February 2023
