|
|
| (142 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| <div class="nonumtoc">__TOC__</div> | | <div class="nonumtoc">__TOC__</div> |
| | {{ombox |
| | | type = notice |
| | | style = width: 960px; |
| | | text = This is sublevel9 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas|my discussion page]] instead.<p></p> |
| | }} |
|
| |
|
| ==3. Choosing laboratory informatics software for your food and beverage lab== | | ==Sandbox begins below== |
| Source: [[LII:Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research/Choosing laboratory informatics software for your lab]]
| |
|
| |
|
| ===3.1 Evaluation and selection===
| | [[File:|right|500px]] |
|
| |
|
| | '''Title''': ''LIMS Selection Guide for Materials Testing Laboratories'' |
|
| |
|
| ====3.1.1 Technology considerations====
| | '''Edition''': First Edition |
| Source: [[LIMS FAQ:What are the key elements of a LIMS for food and beverage testing?]]
| |
|
| |
|
| '''3.1.1.1 Laboratory informatics options''' | | '''Author for citation''': Shawn E. Douglas |
|
| |
|
| | '''License for content''': [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] |
|
| |
|
| ====3.1.2 Features and functions====
| | '''Publication date''': ??? 2023 |
| Source: [[LIMS FAQ:What are the key elements of a LIMS for food and beverage testing?]]
| |
|
| |
|
| ====3.1.3 Cybersecurity considerations====
| |
|
| |
|
| | Description goes here... |
|
| |
|
| ====3.1.4 Regulatory compliance considerations====
| | The table of contents for ''LIMS Selection Guide for Materials Testing Laboratories'' is as follows: |
|
| |
|
| | :[[User:Shawndouglas/sandbox/sublevel10|1. Introduction to materials and materials testing laboratories]] |
| | ::1.1 Materials testing labs, then and now |
| | :::1.1.1 Materials testing 2.0 |
| | ::1.2 Industries, products, and raw materials |
| | ::1.3 Laboratory roles and activities in the industry |
| | :::1.3.1 R&D roles and activities |
| | :::1.3.2 Pre-manufacturing and manufacturing roles and activities |
| | :::1.3.3 Post-production quality control and regulatory roles and activities |
|
| |
|
| ====3.1.5 System flexibility====
| | :[[User:Shawndouglas/sandbox/sublevel11|2. Standards, regulations, and test methods affecting materials testing labs]] |
| | ::2.1 Globally recognized materials manufacturing standards |
| | :::2.1.1 American Society of Civil Engineers (ASCE) materials standards |
| | :::2.1.2 ASTM International Volume 15.04 |
| | :::2.1.3 Canadian Standards Association (CSA) A3000 series |
| | :::2.1.4 International Organization for Standardization (ISO) 10993 |
| | :::2.1.5 Metal Powder Industries Federation (MPIF) Standard 35 family |
| | ::2.2 Regulations and laws around the world |
| | :::2.2.1 21 CFR Part 175 and 176 - United States |
| | :::2.2.2 Building Standard Law - Japan |
| | :::2.2.3 The Furniture and Furnishings (Fire) (Safety) Regulations 1988 - United Kingdom |
| | :::2.2.4 National Environment Protection (Used Packaging Materials) Measure 2011 - Australia |
| | :::2.2.5 Surface Coating Materials Regulations (SOR/2016-193) - Canada |
| | ::2.3 Standardized test methods for materials |
| | ::2.4 Materials laboratory accreditation |
| | :::2.4.1 A note about engineering and construction materials testing |
|
| |
|
| | :[[User:Shawndouglas/sandbox/sublevel12|3. Choosing laboratory informatics software for your materials testing lab]] |
| | ::3.1 Evaluation and selection |
| | :::3.1.1 Technology considerations |
| | ::::3.1.1.1 Laboratory informatics options |
| | :::3.1.2 Features and functions |
| | ::::3.1.2.1 Base features |
| | ::::3.1.2.2 Specialty features |
| | :::3.1.3 Cybersecurity considerations |
| | :::3.1.4 Regulatory compliance considerations |
| | :::3.1.5 System flexibility |
| | :::3.1.6 Cost considerations |
| | ::3.2 Implementation |
| | :::3.2.1 Internal and external integrations |
| | ::3.3 MSW, updates, and other contracted services |
| | ::3.4 How a user requirements specification fits into the entire process (LIMSpec) |
|
| |
|
| ====3.1.6 Cost considerations====
| | :[[User:Shawndouglas/sandbox/sublevel13|4. Resources for selecting and implementing informatics solutions]] |
| | ::4.1 LIMS vendors |
| | ::4.2 Consultants |
| | ::4.3 Professional |
| | :::4.3.1 Trade organizations |
| | :::4.3.2 Conferences and trade shows |
| | ::4.4 LIMSpec |
|
| |
|
| | :[[User:Shawndouglas/sandbox/sublevel14|5. Taking the next step]] |
| | ::5.1 Conduct initial research into a specification document tailored to your lab's needs |
| | ::5.2 Issue some of the specification as part of a request for information (RFI) |
| | ::5.3 Respond to or open dialogue with vendors |
| | :::5.3.1 The value of demonstrations |
| | ::5.4 Finalize the requirements specification and choose a vendor |
|
| |
|
| ===3.2 Implementation===
| | :[[User:Shawndouglas/sandbox/sublevel15|6. Closing remarks]] |
| 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?<ref name="Wagner7Soft19">{{cite web |url=https://blog.walkme.com/7-software-implementation-challenges/ |title=7 Software Implementation Challenges and How to Solve Them |author=Wagner, M. |work=WalkMe Blog |publisher=WalkMe Ltd |date=10 October 2019 |accessdate=06 December 2022}}</ref><ref name="MuraBullet18">{{cite web |url=https://www.userlane.com/software-implementation-plan/ |title=Bullet-Proof Software Implementation Plan: Challenges and Tactics |author=Mura, A. |work=Userlane Digital Adoption Blog |publisher=Userlane GmbH |date=12 July 2018 |accessdate=06 December 2022}}</ref>
| |
|
| |
|
| 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.
| | :[[User:Shawndouglas/sandbox/sublevel16|Appendix 1. Blank LIMSpec template for manufacturing labs]] |
| | | ::A1. Introduction and methodology |
| ====3.2.1 Internal and external integrations====
| | ::A2. Primary laboratory workflow |
| [[File:LabMachines.jpg|right|400px]]Laboratories acquire data management software for many reasons, including improving accuracy, 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.
| | ::A3. Maintaining laboratory workflow and operations |
| | | ::A4. Specialty laboratory functions |
| 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. The LIMS that can support such instrument integrations is increasingly vital to the food and beverage laboratory. Food and beverage 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 interface]]s (APIs) that depend on web services implementation protocols such as REST and SOAP.<ref name="MonusSOAP19">{{cite web |url=https://raygun.com/blog/soap-vs-rest-vs-json/ |title=SOAP vs REST vs JSON - a 2023 comparison |author=Monus, A. |work=Raygun |date=17 October 2022 |accessdate=06 December 2022}}</ref><ref name="LVAQuick18">{{cite web |url=https://www.labvantage.com/a-quick-guide-to-lims-web-services/ |title=A Quick Guide to LIMS Web Services |author=LabVantage Solutions |publisher=LabVantage Solutions, Inc |date=07 January 2018 |accessdate=06 December 2022}}</ref><ref name="GrandOneTool19">{{cite journal |title=One tool to find them all: A case of data integration and querying in a distributed LIMS platform |journal=Database |author=Grand, A.; Geda, E.; Mignone, A. et al. |volume=2019 |page=baz004 |year=2019 |doi=10.1093/database/baz004}}</ref> 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. Perhaps the ERP system needs to create sample batches within the informatics solution, and when testing is done, have the results returned to the ERP. APIs and communication protocols make this happen.<ref name="LVAQuick18" />
| | ::A5. Technology and performance improvements |
| | | ::A6. Security and integrity of systems and operations |
| | | ::A7. Putting those requirements to practical use and caveats |
| ===3.3 MSW, updates, and other contracted services===
| | ::A8. LIMSpec in Microsoft Word format |
| The maintenance, support, and warranty (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.<ref name="ScavoHigh05">{{cite web |url=https://www.computereconomics.com/article.cfm?id=1033 |title=High Software Maintenance Fees and What to Do About Them |author=Scavo, F. |work=Computer Economics |date=08 February 2005 |accessdate=06 December 2022}}</ref> 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.<ref name="Gordon-ByrneMaint14">{{cite web |url=http://www.ittoday.info/ITPerformanceImprovement/Articles/2014-08GordonByrne2.html |archiveurl=https://web.archive.org/web/20210505220938/http://www.ittoday.info/ITPerformanceImprovement/Articles/2014-08GordonByrne2.html |title=Maintenance in the Digital World |author=Gordon-Byrne, G. |work=IT Performance Improvement |publisher=Taylor & Francis, LLC |date=2014 |archivedate=05 May 2021 |accessdate=06 December 2022}}</ref>) 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.<ref name="Gordon-ByrneMaint14" /> 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."<ref name="MWSpec">{{cite web |url=https://www.merriam-webster.com/dictionary/specification |title=specification |work=Merriam-Webster |publisher=Merriam-Webster, Inc |accessdate=06 December 2022}}</ref> 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.<ref name="BiegRequire14">{{cite web |url=https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf |format=PDF |title=Introduction |work=Requirements Management: A Core Competency for Project and Program Success |author=Bieg, D.P. |publisher=Project Management Institute |page=3 |date=August 2014 |accessdate=06 December 2022}}</ref>
| |
| | |
| 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.<ref name="ISO29148">{{cite web |url=https://www.iso.org/standard/72089.html |title=ISO/IEC/IEEE 29148:2018 |publisher=International Organization for Standardization |date=November 2018 |accessdate=06 December 2022}}</ref> The standard describes the characteristics that make up quality software requirement development, including aspects such as<ref name="SeibertHowDoYou11">{{cite web |url=https://hubtechinsider.wordpress.com/2011/07/28/how-do-you-write-software-requirements-what-are-software-requirements-what-is-a-software-requirement/ |title=How do you write software requirements? What are software requirements? What is a software requirement? |work=HubTechInsider |author=Seibert, P. |date=28 July 2011 |accessdate=06 December 2022}}</ref>:
| |
| | |
| *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.
| |
| | |
| 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 user requirements specification (URS), can be used for the selection and acquisition of software or a service.<ref name="MemonSoftware10">{{cite web |url=https://www.cs.umd.edu/~atif/Teaching/Spring2010/Slides/3.pdf |format=PDF |title=Software Requirements: Descriptions and specifications of a system |author=Memon, A. |publisher=University of Maryland |date=Spring 2010 |accessdate=06 December 2022}}</ref><ref name="SchmittUser18">{{cite journal |title=User Requirements Specifications–How Difficult Can It Be? |journal=Pharmaceutical Technology |author=Schmitt, S. |volume=42 |issue=11 |page=58 |year=2018 |url=https://www.pharmtech.com/view/user-requirements-specifications-how-difficult-can-it-be-0 |accessdate=06 December 2022}}</ref> 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.<ref name="SchmittUser18" />
| |
| | |
| The other method has the URS be specific to your business' needs. The process is more work but leaves less to chance.<ref name="SchmittUser18" /> 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.<ref name="AasemAnalysis10">{{cite journal |title=Analysis and optimization of software requirements prioritization techniques |author=Aasem, M.; Ramzan, M.; Jaffar, A. |journal=Proceedings from the 2010 International Conference on Information and Emerging Technologies |pages=1–6 |year=2010 |doi=10.1109/ICIET.2010.5625687}}</ref><ref name="Hirsch10Steps13">{{cite web |url=https://www.phase2technology.com/blog/successful-requirements-gathering |title=10 Steps To Successful Requirements Gathering |author=Hirsch, J. |publisher=Phase2 Technology, LLC |date=22 November 2013 |accessdate=06 December 2022}}</ref><ref name="BurrissSoftware07">{{cite web |url=http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |archiveurl=https://web.archive.org/web/20190925003040/http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |title=Requirements Specification |work=CS451R, University of Missouri–Kansas City |author=Burris, E. |publisher=University of Missouri–Kansas City |date=2007 |archivedate=25 September 2019 |accessdate=06 December 2022}}</ref> 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.
| |
| | |
| In the latter half of this guide, you'll be given an opportunity to see an example of a URS for the food and beverage industry in the form of LIMSpec, an evolving set of software requirements specifications for laboratory informatics systems. Built from requirements found in [[ASTM E1578|ASTM E1578-18]] ''Standard Guide for Laboratory Informatics'', as well as dozens of other standards and regulations, we will use LIMSpec to demonstrate how a URS can be put to use, while also showing you how an informatics system can help you laboratory better meet regulatory requirements.
| |
| | |
| ==References==
| |
| {{Reflist|colwidth=30em}}
| |
