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

From LIMSWiki
Jump to navigationJump to search
Tag: Reverted
 
(110 intermediate revisions by the same user not shown)
Line 7: Line 7:


==Sandbox begins below==
==Sandbox begins below==
{{Infobox software
{{raw:wikipedia::Detection limit}}
| name                  = LIMSpec
| title                  = LIMSpec
| logo                  = <!-- [[File: ]] -->
| screenshot            = [[File:LIMSpecScreenie1.png|400px]]
| caption                =
| collapsible            =
| author                = [[LabLynx, Inc.]]
| developer              = Douglas, S.E.
| released              = {{Start date|2007|06|07}}<ref name="JonesDevelop07">{{cite web |url=http://www.limsfinder.com/BlogDetail.aspx?id=32175_0_29_0_C |archiveurl=https://web.archive.org/web/20160426133105/http://www.limsfinder.com/BlogDetail.aspx?id=32175_0_29_0_C |title=Develop your LIMS Requirements with the LIMSpec Library |author=Jones, J.H. |date=26 June 2007 |archivedate=26 April 2016 |accessdate=28 February 2023}}</ref>
| discontinued          =
| latest release version = 2022 R2
| latest release date    = {{Start date and age|2022|12}}
| latest preview version =
| latest preview date    = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} -->
| frequently updated    = <!-- DO NOT include this parameter unless you know what it does -->
| programming language  =
| operating system      =
| platform              =
| size                  =
| language              =
| status                =
| genre                  =
| license                = [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]
| website                = [[LII:LIMSpec 2022 R2|LIMSpec 2022 R2]] (wiki)<br />[[:File:LIMSpec 2022R2 v1.0.docx|LIMSpec 2022 R2]] (.docx)
}}
 
'''LIMSpec''' is a [[Laboratory|laboratory-focused]], standards-and-regulations-based user requirements specification (URS) for [[laboratory informatics]] software solutions, created to make choosing such software solutions easier and provide practical real-world context for what drives laboratory software development, particularly for regulated industries.
 
==History==
LIMSpec was originated by the [[Laboratory Informatics Institute]] in 2007, intended to ultimately serve as a complete tool for managing the [[Laboratory|laboratory's]] evaluation process for [[laboratory information management system]] (LIMS) and [[laboratory information system]] (LIS) selection. Initially, it was focused on cataloging requirements and vendor questions, and released under a Creative Commons license allowing for the categorization and assignment of requirement to specific industries. In later versions, users could create their own private collection of requirements and questions, and export that collection in a variety of formats.
 
LIMSpec has taken on many different iterations over the years. When originally released in 2007, it was a collection of Microsoft Word documents and eBooks (available on a mailed CD), containing numbered user requirements that could be coded as mandatory, optional, or possible future requirement by the lab, and coded as meeting the requirement, meeting the requirement with customization, or not meeting the requirement by the vendor. Sections were color-coded to delineate who was responsible for completing what.<ref name="JonesDevelop07" /> By 2011, development of LIMSpec and its requirements was opened up to the laboratory informatics community on LinkedIn.<ref name="LIMSpecLI11">{{cite web |url=http://www.linkedin.com/groups?home=&gid=2764592 |archiveurl=https://web.archive.org/web/20110203022008/http://www.linkedin.com/groups?home=&gid=2764592 |title=LiMSpec.com - LIMS requirements development and discussion group |publisher=LinkedIn Corporation |archivedate=03 February 2011 |accessdate=28 February 2023}}</ref> Further efforts to open up LIMSpec development occurred in the mid-2010s, for example on GitHub<ref name="LIMSpecGH15">{{cite web |url=https://github.com/LIMSforge/LiMSpec |archiveurl=https://web.archive.org/web/20150428174318/https://github.com/LIMSforge/LiMSpec |title=LIMSforge/LiMSpec |work=GitHub |date 23 March 2014 |archivedate=28 April 2015 |accessdate=28 February 2023}}</ref> and a [[MediaWiki]] installation<ref name="LIMSpecWiki15">{{cite web |url=http://wiki.limspec.com/index.php/Main_Page |archiveurl=https://web.archive.org/web/20150802015348/http://wiki.limspec.com/index.php/Main_Page |title=Welcome to the Limspec Wiki, a repository of specifications and more for informatics software |work=LIMSpec Wiki |date=27 April 2015 |archivedate=02 August 2015 |accessdate=28 February 2023}}</ref>, giving laboratorians and other stakeholders a more direct online path to engaging with LIMSpec development and use.
 
By 2019, a significant shift in approach to LIMSpec was enacted, driven in part by the 2018 release of [[ASTM E1578|ASTM E1578-18]] ''Standard Guide for Laboratory Informatics''. That standard included a Laboratory Informatics Functional Requirements checklist for [[laboratory informatics]] solutions, making a great foundation for LIMSpec's transformation into a user requirements specification (URS) strictly based off of standards and regulatory sources affecting how laboratories are run. September 2019 saw the release of LIMSpec 2019 R1, based on 70 different sources and made available on LIMSwiki and in a downloadable book format on LIMSforum.<ref name="LIMSPEC19R1">{{cite web |url=https://www.limswiki.org/index.php?title=Book:LIMSpec_2022_R2&oldid=36380 |title=LIMSpec 2019 R1 |author=Douglas, S.E. |work=LIMSwiki |date=20 September 2019 |accessdate=28 February 2023}}</ref> With the latest iteration—[[LII:LIMSpec 2022 R2|LIMSpec 2022 R2]]—adding more than 30 new sources of standards and compliance, LIMSpec continues to grow as a [[LabLynx, Inc.|LabLynx-supported]] URS based on real-world needs of laboratories.
 
==Methodology==
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=28 February 2023}}</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=28 February 2023}}</ref>
 
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 have 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.<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=28 February 2023}}</ref><ref name="BurrissSoftware07">{{cite web |url=http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |archiveurl=https://web.archive.org/web/20190724173601/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=24 July 2019 |accessdate=28 February 2023}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal |title=Requirements engineering as a success factor in software projects |author=Hofmann, H.F.; Lehner, F. |journal=IEEE Software |volume=18 |issue=4 |pages=58–66 |year=2001 |doi=10.1109/MS.2001.936219}}</ref> (including for past iterations of LIMSpec), sometimes a fresh approach is required. Why not tie a software solution's functionality to the requirements of meeting laboratory standards, regulations, guidelines, and best practices?
 
The latest iteration of LIMSpec is grounded in ASTM E1578-18 ''Standard Guide for Laboratory Informatics'' at its core, with more than 130 additional sources being tapped into, including [[21 CFR Part 11]], [[ISO 15189]], and Safe Food for Canadians Regulations, as well as various E.U. Commission Directives and World Health Organization (WHO) Technical Reports. As more sources get added to LIMSpec, it becomes more robust and relevant to more industries with laboratories. Those sources are linked to one or more individual requirement statements spanning multiple aspects of laboratory operations (see the screenshot in the information box, above). In some cases, the standards and guidelines 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 due to their proprietary nature or cost. For example, the AOAC International ''Official Methods of Analysis'' and ''Guidelines for Laboratories Performing Microbiological and Chemical Analyses of Food, Dietary Supplements, and Pharmaceuticals'' are both proprietary and more or less prohibitively expensive. In other cases, such as with the U.S. Food Emergency Response Network and Laboratory Response Network, they simply don't make their standardized procedures open to the public and thus can't be included.
 
The LIMSpec is maintained and added to periodically as time allows and necessity dictates.
 
==Organization==
The LIMSpec 2022 R2 document is divided into five distinct sections, with numerous subsections in each:
 
* Primary Laboratory Workflow
** 1. Sample and experiment registration
** 2. Sample management
** 3. Core laboratory testing and experiments
** 4. Results review and verification
** 5. Sample, experiment, and study approval and verification
** 6. Reporting
* Maintaining Laboratory Workflow and Operations
** 7. Document and records management
** 8. Resource management
** 9. Compliance management
** 10. Instrument and equipment management
** 11. Batch and lot management
** 12. Scheduled event management
** 13. Instrument data capture and control
** 14. Standard and reagent management
** 15. Inventory management
** 16. Investigation and quality management
* Specialty Laboratory Functions (minus non-relevant industries)
** 17. Production management
** 18. Statistical trending and control charts
** 19. Agriculture and food data management
** 20. Environmental data management
** 21. Forensic case and data management
** 22. Clinical and public health data management
** 23. Veterinary data management
** 24. Scientific data management
** 25. Health information technology
* Technology and Performance Improvements
** 26. Instrument data systems functions
** 27. Systems integration
** 28. Laboratory scheduling and capacity planning
** 29. Lean laboratory and continuous improvement
** 30. Artificial intelligence and smart systems
* Security and Integrity of Systems and Operations
** 31. Data integrity
** 32. Configuration management
** 33. System validation and commission
** 34. System administration
** 35. Cybersecurity
** 36. Information privacy
 
These sections and subsections should be able to address most any requirement you have for your system. Of course, if something isn't covered by LIMSpec, you can always add additional requirements.
 
==Using LIMSpec==
As noted, LIMSpec's requirement are all based on not just the ASTM E1578 standard but also a wide variety of other sources. That ultimately means a foundational reasoning is provided for each requirement, not necessarily a "just because I want it" reasoning. As foundational requirements, LIMSpec should thus operate as an excellent starting point for building your own URS or for researching the best laboratory informatics solution for your laboratory. Some laboratories may want to look at LIMSpec as a checklist of possible requirements for a LIMS or LIS they are shopping for, or they may want to use LIMSpec as a base for a [[request for information]] (RFI) directed at laboratory informatics vendors.
 
In either case, an initial set of critical requirements will be born out of using a specification document like LIMSpec to develop your URS. It is more work to go this route, but turning to an initial URS leaves less to chance.<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=28 February 2023}}</ref> Developing your own URS isn't always straightforward. During the initial research towards your URS, you won't have to (and shouldn't) include every LIMSpec requirement for when you approach potential vendors. Most vendors appreciate a more inviting approach that doesn't overwhelm, at least initially. You will want to go with a limited yet practical set of requirements carefully chosen because they matter to you and your laboratory the most. Wherever you choose to start, you'll likely want to wait until after participating in several software demonstrations before even considering your URS to be complete. However, 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.
 
If issuing an RFI, again, the user will want to carefully select LIMSpec requirements that are most critical to its laboratory operations. For example, a lab complying with [[ISO/IEC 17025]] may want to focus on [[LII:LIMS Selection Guide for ISO/IEC 17025 Laboratories/Choosing laboratory informatics software for better ISO/IEC 17025 compliance#3.1.2 Features and functions for ISO/IEC 17025 compliance|requirements specific to that standard]], at least initially. Remember, an RFI is not meant to answer all of your questions in the initial discovery phase. The RFI is meant as a means to help narrow down your search to a few quality candidates while learning more about each other.<ref name="HolmesItsAMatch">{{cite web |url=https://allcloud.io/blog/its-a-match-how-to-run-a-good-rfi-rfp-or-rfq-and-find-the-right-partner/ |title=It's a Match: How to Run a Good RFI, RFP, or RFQ and Find the Right Partner |author=Holmes, T. |work=AllCloud Blog |accessdate=28 February 2023}}</ref> Once the RFI process is complete, software demonstrations have been attended, and the pool of potential software vendors is narrowed down, you then can broadly add more requirements to the original collection of critical requirements from the RFI to ensure those providers meet all or most of your needs. That said, be cognizant that there may be no vendor that can meet each and every need of your lab. Your lab will have to make important decisions about which requirements are non-negotiable and which are more flexible. The vendors you engage with may be able to provide realistic advice in this regard, based upon your lab's requirements and their past experience with labs. As such, those vendors with real-world experience meeting the needs of your laboratory's industry may have a strong leg up on other vendors.
 
==References==
{{Reflist|colwidth=30em}}

Latest revision as of 18:25, 10 January 2024

Sandbox begins below

Template:Short description

The limit of detection (LOD or LoD) is the lowest signal, or the lowest corresponding quantity to be determined (or extracted) from the signal, that can be observed with a sufficient degree of confidence or statistical significance. However, the exact threshold (level of decision) used to decide when a signal significantly emerges above the continuously fluctuating background noise remains arbitrary and is a matter of policy and often of debate among scientists, statisticians and regulators depending on the stakes in different fields.

Significance in analytical chemistry

In analytical chemistry, the detection limit, lower limit of detection, also termed LOD for limit of detection or analytical sensitivity (not to be confused with statistical sensitivity), is the lowest quantity of a substance that can be distinguished from the absence of that substance (a blank value) with a stated confidence level (generally 99%).[1][2][3] The detection limit is estimated from the mean of the blank, the standard deviation of the blank, the slope (analytical sensitivity) of the calibration plot and a defined confidence factor (e.g. 3.2 being the most accepted value for this arbitrary value).[4] Another consideration that affects the detection limit is the adequacy and the accuracy of the model used to predict concentration from the raw analytical signal.[5]

As a typical example, from a calibration plot following a linear equation taken here as the simplest possible model:

where, corresponds to the signal measured (e.g. voltage, luminescence, energy, etc.), "Template:Mvar" the value in which the straight line cuts the ordinates axis, "Template:Mvar" the sensitivity of the system (i.e., the slope of the line, or the function relating the measured signal to the quantity to be determined) and "Template:Mvar" the value of the quantity (e.g. temperature, concentration, pH, etc.) to be determined from the signal ,[6] the LOD for "Template:Mvar" is calculated as the "Template:Mvar" value in which equals to the average value of blanks "Template:Mvar" plus "Template:Mvar" times its standard deviation "Template:Mvar" (or, if zero, the standard deviation corresponding to the lowest value measured) where "Template:Mvar" is the chosen confidence value (e.g. for a confidence of 95% it can be considered Template:Mvar = 3.2, determined from the limit of blank).[4]

Thus, in this didactic example:

There are a number of concepts derived from the detection limit that are commonly used. These include the instrument detection limit (IDL), the method detection limit (MDL), the practical quantitation limit (PQL), and the limit of quantitation (LOQ). Even when the same terminology is used, there can be differences in the LOD according to nuances of what definition is used and what type of noise contributes to the measurement and calibration.[7]

The figure below illustrates the relationship between the blank, the limit of detection (LOD), and the limit of quantitation (LOQ) by showing the probability density function for normally distributed measurements at the blank, at the LOD defined as 3 × standard deviation of the blank, and at the LOQ defined as 10 × standard deviation of the blank. (The identical spread along Abscissa of these two functions is problematic.) For a signal at the LOD, the alpha error (probability of false positive) is small (1%). However, the beta error (probability of a false negative) is 50% for a sample that has a concentration at the LOD (red line). This means a sample could contain an impurity at the LOD, but there is a 50% chance that a measurement would give a result less than the LOD. At the LOQ (blue line), there is minimal chance of a false negative.

Template:Wide image

Instrument detection limit

Most analytical instruments produce a signal even when a blank (matrix without analyte) is analyzed. This signal is referred to as the noise level. The instrument detection limit (IDL) is the analyte concentration that is required to produce a signal greater than three times the standard deviation of the noise level. This may be practically measured by analyzing 8 or more standards at the estimated IDL then calculating the standard deviation from the measured concentrations of those standards.

The detection limit (according to IUPAC) is the smallest concentration, or the smallest absolute amount, of analyte that has a signal statistically significantly larger than the signal arising from the repeated measurements of a reagent blank.

Mathematically, the analyte's signal at the detection limit () is given by:

where, is the mean value of the signal for a reagent blank measured multiple times, and is the known standard deviation for the reagent blank's signal.

Other approaches for defining the detection limit have also been developed. In atomic absorption spectrometry usually the detection limit is determined for a certain element by analyzing a diluted solution of this element and recording the corresponding absorbance at a given wavelength. The measurement is repeated 10 times. The 3σ of the recorded absorbance signal can be considered as the detection limit for the specific element under the experimental conditions: selected wavelength, type of flame or graphite oven, chemical matrix, presence of interfering substances, instrument... .

Method detection limit

Often there is more to the analytical method than just performing a reaction or submitting the analyte to direct analysis. Many analytical methods developed in the laboratory, especially these involving the use of a delicate scientific instrument, require a sample preparation, or a pretreatment of the samples prior to being analysed. For example, it might be necessary to heat a sample that is to be analyzed for a particular metal with the addition of acid first (digestion process). The sample may also be diluted or concentrated prior to analysis by means of a given instrument. Additional steps in an analysis method add additional opportunities for errors. Since detection limits are defined in terms of errors, this will naturally increase the measured detection limit. This "global" detection limit (including all the steps of the analysis method) is called the method detection limit (MDL). The practical way for determining the MDL is to analyze seven samples of concentration near the expected limit of detection. The standard deviation is then determined. The one-sided Student's t-distribution is determined and multiplied versus the determined standard deviation. For seven samples (with six degrees of freedom) the t value for a 99% confidence level is 3.14. Rather than performing the complete analysis of seven identical samples, if the Instrument Detection Limit is known, the MDL may be estimated by multiplying the Instrument Detection Limit, or Lower Level of Detection, by the dilution prior to analyzing the sample solution with the instrument. This estimation, however, ignores any uncertainty that arises from performing the sample preparation and will therefore probably underestimate the true MDL.

Limit of each model

The issue of limit of detection, or limit of quantification, is encountered in all scientific disciplines. This explains the variety of definitions and the diversity of juridiction specific solutions developed to address preferences. In the simplest cases as in nuclear and chemical measurements, definitions and approaches have probably received the clearer and the simplest solutions. In biochemical tests and in biological experiments depending on many more intricate factors, the situation involving false positive and false negative responses is more delicate to handle. In many other disciplines such as geochemistry, seismology, astronomy, dendrochronology, climatology, life sciences in general, and in many other fields impossible to enumerate extensively, the problem is wider and deals with signal extraction out of a background of noise. It involves complex statistical analysis procedures and therefore it also depends on the models used,[5] the hypotheses and the simplifications or approximations to be made to handle and manage uncertainties. When the data resolution is poor and different signals overlap, different deconvolution procedures are applied to extract parameters. The use of different phenomenological, mathematical and statistical models may also complicate the exact mathematical definition of limit of detection and how it is calculated. This explains why it is not easy to come to a general consensus, if any, about the precise mathematical definition of the expression of limit of detection. However, one thing is clear: it always requires a sufficient number of data (or accumulated data) and a rigorous statistical analysis to render better signification statistically.

Limit of quantification

The limit of quantification (LoQ, or LOQ) is the lowest value of a signal (or concentration, activity, response...) that can be quantified with acceptable precision and accuracy.

The LoQ is the limit at which the difference between two distinct signals / values can be discerned with a reasonable certainty, i.e., when the signal is statistically different from the background. The LoQ may be drastically different between laboratories, so another detection limit is commonly used that is referred to as the Practical Quantification Limit (PQL).

See also

References

  1. IUPAC, Compendium of Chemical Terminology, 2nd ed. (the "Gold Book") (1997). Online corrected version:  (2006–) "detection limit".
  2. "Guidelines for Data Acquisition and Data Quality Evaluation in Environmental Chemistry". Analytical Chemistry 52 (14): 2242–49. 1980. doi:10.1021/ac50064a004. 
  3. Saah AJ, Hoover DR (1998). "[Sensitivity and specificity revisited: significance of the terms in analytic and diagnostic language."]. Ann Dermatol Venereol 125 (4): 291–4. PMID 9747274. https://pubmed.ncbi.nlm.nih.gov/9747274. 
  4. 4.0 4.1 "Limit of blank, limit of detection and limit of quantitation". The Clinical Biochemist. Reviews 29 Suppl 1 (1): S49–S52. August 2008. PMC 2556583. PMID 18852857. https://www.ncbi.nlm.nih.gov/pmc/articles/2556583. 
  5. 5.0 5.1 "R: "Detection" limit for each model" (in English). search.r-project.org. https://search.r-project.org/CRAN/refmans/bioOED/html/calculate_limit.html. 
  6. "Signal enhancement on gold nanoparticle-based lateral flow tests using cellulose nanofibers". Biosensors & Bioelectronics 141: 111407. September 2019. doi:10.1016/j.bios.2019.111407. PMID 31207571. http://ddd.uab.cat/record/218082. 
  7. Long, Gary L.; Winefordner, J. D., "Limit of detection: a closer look at the IUPAC definition", Anal. Chem. 55 (7): 712A–724A, doi:10.1021/ac00258a724 

Further reading

  • "Limits for qualitative detection and quantitative determination. Application to radiochemistry". Analytical Chemistry 40 (3): 586–593. 1968. doi:10.1021/ac60259a007. ISSN 0003-2700. 

External links

Template:BranchesofChemistry Template:Authority control