LII:LIMSpec/Introduction and methodology

Introduction

Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something." 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.

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. The standard describes the characteristics that make up quality software requirement development, including aspects such as:

• 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. Once compiled, a set of requirements can serve not only to strengthen the software requirements specification, but the requirements set can also be used for bidding on a contract or serve as the basis for a specific contract that is being finalized.

Over the years, a wide variety of companies, consultants, and researchers have compiled public and private software requirements specifications for laboratory informatics systems. These compiled lists of requirements for how a given laboratory informatics solution should be developed, delivered, and maintained have changed as technology and user demand evolved. Often times, these requirements documents turn 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 they do in fact have to be prioritized as "nice to have" or "essential to system operation," or something in between. While this reasonable mix of requirements has served informatics software developers well, sometimes a fresh approach is required.

What follows is an attempt to look less at the wishlists of laboratories and more directly at what requirements current regulatory schemes, industry standards, and organizational guidelines place on the ever-evolving array of laboratory informatics systems being developed today. What does the United States' 21 CFR Part 11 have to say about how your laboratory information management system (LIMS), laboratory information system (LIS), electronic laboratory notebook (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines. The final chapter discusses how to best put this requirements specification to use.

Methodology

At its core, this LIMSpec—which has seen several iterations over the years—is rooted in ASTM E1578-18 Standard Guide for Laboratory Informatics. With the latest version released in 2018, an updated Laboratory Informatics Functional Requirements checklist is included in the appendix, which "covers functionality common to the various laboratory informatics systems discussed throughout [the] guide as well as requirements recommended as part of [the] guide." It goes on to state that the checklist "is an example of typical requirements that can be used to guide the purchase, upgrade, or development of a laboratory informatics system," though it is certainly "not meant to be exhaustive."

This LIMSpec borrows from that requirements checklist and then adds more to it from a wide variety of sources. An attempt has been made to find the most relevant regulations, standards, and guidance that shape how a compliant laboratory informatics system is developed and maintained. However, this should definitely be considered a work in progress, with more to be added with additional public and private comment on missing sources.

That said, this first revision taps into the following sources:

• 7 CFR Part 331
• 9 CFR Part 121
• 21 CFR Part 7
• 21 CFR Part 11
• 21 CFR Part 58
• 21 CFR Part 211
• 21 CFR Part 212
• 21 CFR Part 225
• 21 CFR Part 226
• 21 CFR Part 312
• 21 CFR Part 606
• 21 CFR Part 810
• 21 CFR Part 812
• 21 CFR Part 820
• 29 CFR Part 1910.120
• 29 CFR Part 1910.134
• 29 CFR Part 1910.1030
• 29 CFR Part 1910.1096
• 29 CFR Part 1910.1200
• 29 CFR Part 1910.1450
• 40 CFR Part 3
• 40 CFR Part 60
• 40 CFR Part 62
• 40 CFR Part 63
• 40 CFR Part 141
• 40 CFR Part 370
• 40 CFR Part 372
• 40 CFR Part 704
• 40 CFR Part 717
• 40 CFR Part 720
• 42 CFR Part 73
• 42 CFR Part 493
• 45 CFR Part 160
• 45 CFR Part 162
• 45 CFR Part 164
• 45 CFR Part 170
• AAFCO QA/QC Guidelines for Feed Laboratories
• AAVLD Requirements for an AVMDL
• ABFT Accreditation Manual
• AIHA-LAP Policies 2018
• ASCLD/LAB Supp. Reqs. for the Accreditation of Forensic Science Testing Laboratories
• ASTM E1188-11
• ASTM E1459-13
• ASTM E1492-11
• ASTM E1578-18
• CDC PHIN Messaging System
• CJIS Security Policy
• E.U. Annex 11
• E.U. Commission Directive 2003/94/EC
• EPA 815-R-05-004
• EPA ERLN Laboratory Requirements v1.6
• EPA Metadata Technical Specification
• EPA QA/G-5
• EPA SEDD Specification and Data Element Dictionary v5.2
• FDA eLEXNET Data Exchange Program
• FDA Hazard Analysis Critical Control Point (HACCP)
• ICAR 15 Data Exchange
• ISO 15189:2012
• ISO/IEC 17025:2017
• NAHLN HL7 Messaging Quick User Guide
• NAHLN Information Technology System
• OECD GLP Principles
• USDA Administrative Procedures for the Pesticide Data Program (PDP)
• USDA Data and Instrumentation for PDP
• USDA Sample Processing and Analysis Procedures for PDP
• USDA Sampling Procedures for PDP
• VeNom Coding Group terminology
• Veterinary Terminology Services Laboratory terminology
• VICH GL53
• WHO Technical Report Series, #986, Annex 2

Each requirement statement has at least one linked regulation, standard, or guidance item. In some cases, the standards covered are proprietary. In those cases, the standard was either purchased for review or heavily researched using supporting documentation, and the link goes to the acquisition page for the standard. In other cases, some sources have been intentionally omitted. For example, the AOAC International Official Methods of Analysis are both proprietary and more or less prohibitively expensive. In other cases such as the U.S. Food Emergency Response Network and Laboratory Response Network, they simply don't make their standardized procedures open to the public.