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

From LIMSWiki
Jump to navigationJump to search
 
(129 intermediate revisions by the same user not shown)
Line 8: Line 8:
==Sandbox begins below==
==Sandbox begins below==
<div class="nonumtoc">__TOC__</div>
<div class="nonumtoc">__TOC__</div>
[[File:Icos Laboratories.JPG|thumb|360px|right|Laboratories around the world depend on a LIMS to manage data, assign rights, manage inventory, and more.]]
[[File:FAIRResourcesGraphic AustralianResearchDataCommons 2018.png|right|520px]]
Sometimes referred to as a [[laboratory information system]] (LIS) or laboratory management system (LMS), a '''laboratory information management system''' (LIMS) is a software-based [[laboratory]] and [[information management]] system that offers a set of key features that support a modern laboratory's operations. Those key features include—but are not limited to—[[Workflow|workflow]] and data tracking support, flexible architecture, and smart data exchange interfaces, which fully "support its use in regulated environments."<ref name="SapioWhatIs10">{{cite web |url=http://sapiosciences.blogspot.com/2010/07/so-what-is-lims.html |archiveurl=https://web.archive.org/web/20160304102056/http://sapiosciences.blogspot.com/2010/07/so-what-is-lims.html |title=So what is a LIMS? |work=Laboratory Information Management |publisher=Sapio Sciences |date=28 July 2010 |archivedate=04 March 2016 |accessdate=12 March 2024}}</ref> The features and uses of a LIMS have evolved over the years from simple [[sample]] tracking to an integrated application that handles laboratory management, [[Quality (business)|quality]] management, and enterprise resource planning processes, from testing and [[quality control]] to reporting and invoicing.
'''Title''': ''What are the potential implications of the FAIR data principles to laboratory informatics applications?''


Due to the rapid pace at which laboratories and their data management needs shift, the definition of LIMS has become somewhat controversial. As the needs of the modern laboratory vary widely from lab to lab, what is needed from a LIMS also shifts. The end result: the definition of a LIMS will shift based on who you ask and what their vision of the modern lab is.<ref name="SapioWhatIs10" /> Dr. Alan McLelland of the Institute of Biochemistry, Royal Infirmary, Glasgow highlighted this problem in the late 1990s by explaining how a LIMS is perceived by an analyst, a laboratory manager, an information systems manager, and an accountant, "all of them correct, but each of them limited by the users' own perceptions."<ref name="McLelland98">{{cite web |url=http://www.rsc.org/pdf/andiv/tech.pdf |archiveurl=https://web.archive.org/web/20131004232754/http://www.rsc.org/pdf/andiv/tech.pdf |format=PDF |title=What is a LIMS - a laboratory toy, or a critical IT component? |author=McLelland, A. |publisher=Royal Society of Chemistry |page=1 |date=1998 |archivedate=04 October 2013 |accessdate=12 March 2024}}</ref>
'''Author for citation''': Shawn E. Douglas


Historically the term "LIMS" has tended to be used to reference [[laboratory informatics]] systems targeted for environmental, research, or industrial analysis such as water quality, pharmaceutical, or petrochemical work. "LIS" has tended to be used to reference informatics systems in the [[Forensic science|forensics]] and clinical markets, which often requires special case and patient management tools. In modern times, LIMS functionality has spread even farther beyond its original purpose of sample management. [[Assay]] data management, data mining, statistical analysis, [[Electronic laboratory notebook|electronic laboratory notebook]] (ELN) integration, and industry-specific functionality that supports regulatory requirements in that industry (e.g., [[hazard analysis and critical control points]] [HACCP] workflow tools in food and beverage manufacturing) are all types of functionality added to LIMS, enabling the realization of greater laboratory and enterprise management through one software solution. Additionally, the distinction between a LIMS and a LIS has blurred, as many LIMS now also fully support comprehensive case-centric clinical specimen and patient data management.
'''License for content''': [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International]


==History==
'''Publication date''': May 2024
Up until the late 1970s, management of laboratory samples and their associated analysis and reporting was a time-consuming manual processes often riddled with transcription errors. This gave some organizations impetus to streamline the collection of data and how it was reported. Custom in-house solutions were developed by a few individual laboratories, while some enterprising entities at the same time sought to develop a more commercial reporting solution in the form of special instrument-based systems.<ref name="LIMSHistory">{{cite journal |title=A brief history of LIMS |journal=Laboratory Automation and Information Management |author=Gibbon, G.A. |volume=32 |issue=1 |pages=1–5 |year=1996 |doi=10.1016/1381-141X(95)00024-K}}</ref>


In 1982, the first generation of LIMS was introduced in the form of a single centralized minicomputer, which offered laboratories the first opportunity to utilize automated reporting tools. As the interest in these early LIMS grew, industry leaders like Gerst Gibbon of the Federal Energy Technology Centre in Pittsburgh began planting the seeds through LIMS-related conferences. By 1988, the second-generation commercial offerings were tapping into [[Relational database|relational databases]] to expand LIMS into more application-specific territory, and international LIMS conferences were in full swing. As personal computers became more powerful and prominent, a third generation of LIMS emerged in the early 1990s. These new LIMS took advantage of the developing client/server architecture, allowing laboratories to implement better data processing and exchanges.<ref name="LIMSHistory" />
==Introduction==


By 1995, the client/server tools had developed to the point of allowing processing of data anywhere on the network. Web-enabled LIMS were introduced the following year, enabling researchers to extend operations outside the confines of the laboratory. From 1996 to 2002, additional functionality was included in LIMS, from wireless networking capabilities and georeferencing of samples, to the adoption of [[XML]] standards and the development of internet-based purchasing.<ref name="LIMSHistory" />
This brief topical article will examine


By the early 2010s, some LIMS had added additional characteristics that continued to shape how a LIMS was defined. Examples include the addition of clinical functionality and [[electronic laboratory notebook]] (ELN) functionality, as well a rise in the cloud-based [[software as a service]] (SaaS) distribution model.<ref name="LinkedInSaaSModel">{{cite web |url=https://www.linkedin.com/feed/update/urn:li:groupPost:2069898-181604484/ |title=Is any one aware of a SaaS LIMS success story? |author=Nagisetty, P. |publisher=LinkedIn |date=02 November 2012 |accessdate=12 March 2024}}</ref><ref name="MullinLIMS10">{{cite journal |title=LIMS in the Cloud |journal=Chemical & Engineering News |author=Mullin, R. |volume=88 |issue=21 |pages=12–16 |date=24 May 2010 |url=http://cen.acs.org/articles/88/i21/LIMS-Cloud.html |accessdate=12 March 2024}}</ref> By the late 2010s, cloud-based LIMS were more numerous in quantity and adoption but not the ''de facto'' standard, as the costs and daunting nature associated with vendors transitioning legacy products to the cloud and with companies trying to integrate a cloud-based LIMS into a complicated IT and regulatory environment had partially stymied growth.<ref name="KnippenbergMoving17">{{cite web |url=https://astrixinc.com/moving-lab-infrastructure-cloud-consider-nearshoring/ |archiveurl=https://web.archive.org/web/20230131012812/https://astrixinc.com/moving-lab-infrastructure-cloud-consider-nearshoring/ |title=Moving your Lab IT Infrastructure to the Cloud? Consider Nearshoring |author=Knippenberg, R. |work=Astrix Blog |publisher=Astrix Technology Group |date=09 May 2017 |archivedate=31 January 2023 |accessdate=12 March 2024}}</ref><ref name="JoyceWhatYou17">{{cite web |url=https://www.labmanager.com/what-you-and-your-it-team-should-know-about-the-cloud-3048 |title=What You and Your IT Team Should Know About the Cloud |work=Lab Manager |author=Joyce, J. |publisher=LabX Media Group |date=01 May 2017 |accessdate=12 March 2024}}</ref> Today, despite these challenges, cloud-based approaches to the management of laboratory data continue to see adoption or intent to adopt<ref name="AstrixProgress22">{{cite web |url=https://astrixinc.com/wp-content/uploads/2022/06/Progress-Snapshot-on-Enabling-the-Digital-Lab-of-the-Future-v4a.pdf |format=PDF |title=2022 Laboratory Informatics: Progress Snapshot on Enabling the Digital Lab of the Future |publisher=Astrix Technology, LLC |pages=18–23 |date=June 2022 |accessdate=12 March 2024}}</ref><ref name="Lanewala2024LIMS24">{{cite web |url=https://clarkstonconsulting.com/insights/2024-lims-trends/ |title=2024 LIMS Trends |author=Lanewala, M.; Yauger, T.; Jones, L.L. |work=Clarkston Consulting Insights |publisher=Clarkston Consulting |date=04 March 2024 |accessdate=12 March 2024}}</ref>, including in the more heavily regulated GxP (good practice) laboratories, which have their own unique challenges with [[data integrity]] and [[Information security|security]] requirements.<ref>{{Cite journal |last=Davis |first=Scott |last2=Usansky |first2=Joel |last3=Mitra-Kaushik |first3=Shibani |last4=Kellie |first4=John |last5=Honrine |first5=Kimberly |last6=Woolf |first6=Eric |last7=Adams |first7=Jeb |last8=Kelly |first8=Ryan |last9=Evens |first9=John |last10=Pine |first10=Samuel |last11=Hochreiner |first11=Hannes |date=2021-09 |title=Cloud solutions for GxP laboratories: considerations for data storage |url=https://www.future-science.com/doi/10.4155/bio-2021-0137 |journal=Bioanalysis |language=en |volume=13 |issue=17 |pages=1313–1321 |doi=10.4155/bio-2021-0137 |issn=1757-6180}}</ref>
==The "FAIR-ification" of research objects and software==
First discussed during a 2014 FORCE-11 workshop dedicated to "overcoming data discovery and reuse obstacles," the [[Journal:The FAIR Guiding Principles for scientific data management and stewardship|FAIR data principles]] were published by Wilkinson ''et al.'' in 2016 as a stakeholder collaboration driven to see research "objects" (i.e., research data and [[information]] of all shapes and formats) become more universally findable, accessible, interoperable, and reusable (FAIR) by both machines and people.<ref name="WilkinsonTheFAIR16">{{Cite journal |last=Wilkinson |first=Mark D. |last2=Dumontier |first2=Michel |last3=Aalbersberg |first3=IJsbrand Jan |last4=Appleton |first4=Gabrielle |last5=Axton |first5=Myles |last6=Baak |first6=Arie |last7=Blomberg |first7=Niklas |last8=Boiten |first8=Jan-Willem |last9=da Silva Santos |first9=Luiz Bonino |last10=Bourne |first10=Philip E. |last11=Bouwman |first11=Jildau |date=2016-03-15 |title=The FAIR Guiding Principles for scientific data management and stewardship |url=https://www.nature.com/articles/sdata201618 |journal=Scientific Data |language=en |volume=3 |issue=1 |pages=160018 |doi=10.1038/sdata.2016.18 |issn=2052-4463 |pmc=PMC4792175 |pmid=26978244}}</ref> The authors released the FAIR principles while recognizing that "one of the grand challenges of data-intensive science ... is to improve knowledge discovery through assisting both humans and their computational agents in the discovery of, access to, and integration and analysis of task-appropriate scientific data and other scholarly digital objects."<ref name="WilkinsonTheFAIR16" />


==Purpose and technology==
Since 2016, other research stakeholders have taken to publishing their thoughts about how the FAIR principles apply to their fields of study and practice<ref name="NIHPubMedSearch">{{cite web |url=https://pubmed.ncbi.nlm.nih.gov/?term=fair+data+principles |title=fair data principles |work=PubMed Search |publisher=National Institutes of Health, National Library of Medicine |accessdate=30 April 2024}}</ref>, including in ways beyond what perhaps was originally imagined by Wilkinson ''et al.''. For example, multiple authors have examined whether or not the software used in scientific endeavors itself can be considered a research object worth being developed and managed in tandem with the FAIR data principles.<ref>{{Cite journal |last=Hasselbring |first=Wilhelm |last2=Carr |first2=Leslie |last3=Hettrick |first3=Simon |last4=Packer |first4=Heather |last5=Tiropanis |first5=Thanassis |date=2020-02-25 |title=From FAIR research data toward FAIR and open research software |url=https://www.degruyter.com/document/doi/10.1515/itit-2019-0040/html |journal=it - Information Technology |language=en |volume=62 |issue=1 |pages=39–47 |doi=10.1515/itit-2019-0040 |issn=2196-7032}}</ref><ref name="GruenpeterFAIRPlus20">{{Cite web |last=Gruenpeter, M. |date=23 November 2020 |title=FAIR + Software: Decoding the principles |url=https://www.fairsfair.eu/sites/default/files/FAIR%20%2B%20software.pdf |format=PDF |publisher=FAIRsFAIR “Fostering FAIR Data Practices In Europe” |accessdate=30 April 2024}}</ref><ref>{{Cite journal |last=Barker |first=Michelle |last2=Chue Hong |first2=Neil P. |last3=Katz |first3=Daniel S. |last4=Lamprecht |first4=Anna-Lena |last5=Martinez-Ortiz |first5=Carlos |last6=Psomopoulos |first6=Fotis |last7=Harrow |first7=Jennifer |last8=Castro |first8=Leyla Jael |last9=Gruenpeter |first9=Morane |last10=Martinez |first10=Paula Andrea |last11=Honeyman |first11=Tom |date=2022-10-14 |title=Introducing the FAIR Principles for research software |url=https://www.nature.com/articles/s41597-022-01710-x |journal=Scientific Data |language=en |volume=9 |issue=1 |pages=622 |doi=10.1038/s41597-022-01710-x |issn=2052-4463 |pmc=PMC9562067 |pmid=36241754}}</ref><ref>{{Cite journal |last=Patel |first=Bhavesh |last2=Soundarajan |first2=Sanjay |last3=Ménager |first3=Hervé |last4=Hu |first4=Zicheng |date=2023-08-23 |title=Making Biomedical Research Software FAIR: Actionable Step-by-step Guidelines with a User-support Tool |url=https://www.nature.com/articles/s41597-023-02463-x |journal=Scientific Data |language=en |volume=10 |issue=1 |pages=557 |doi=10.1038/s41597-023-02463-x |issn=2052-4463 |pmc=PMC10447492 |pmid=37612312}}</ref><ref>{{Cite journal |last=Du |first=Xinsong |last2=Dastmalchi |first2=Farhad |last3=Ye |first3=Hao |last4=Garrett |first4=Timothy J. |last5=Diller |first5=Matthew A. |last6=Liu |first6=Mei |last7=Hogan |first7=William R. |last8=Brochhausen |first8=Mathias |last9=Lemas |first9=Dominick J. |date=2023-02-06 |title=Evaluating LC-HRMS metabolomics data processing software using FAIR principles for research software |url=https://link.springer.com/10.1007/s11306-023-01974-3 |journal=Metabolomics |language=en |volume=19 |issue=2 |pages=11 |doi=10.1007/s11306-023-01974-3 |issn=1573-3890}}</ref> Researchers quickly recognized that any planning around updating processes and systems to make research objects more FAIR would have to be tailored to specific research contexts, recognize that digital research objects go beyond data and information, and recognize "the specific nature of software" and not consider it "just data."<ref name="GruenpeterFAIRPlus20" /> The end result has been applying the core concepts of FAIR but differently from data, with the added context of research software being more than just data, requiring more nuance and a different type of planning from applying FAIR to digital data and information.
A LIMS is a software solution designed to allow end users to better manage a wide variety of operational and quality management aspects of academic, government, and industrial laboratories serving a broad range of industries and stakeholders. The software can be monolithic or microservices-based, with each architecture type having its own pros and cons, especially dependent upon the number of concurrent users, desired functional scale, and deployment method (e.g., on-premises vs. [[Cloud computing|in the cloud]]).<ref>{{Cite journal |last=Blinowski |first=Grzegorz |last2=Ojdowska |first2=Anna |last3=Przybylek |first3=Adam |date=2022 |title=Monolithic vs. Microservice Architecture: A Performance and Scalability Evaluation |url=https://ieeexplore.ieee.org/document/9717259/ |journal=IEEE Access |volume=10 |pages=20357–20374 |doi=10.1109/ACCESS.2022.3152803 |issn=2169-3536}}</ref> The reasons for adopting a LIMS and other [[laboratory informatics]] solutions varies by laboratory, but common purposes for adopting such systems include wanting to automate and better manage laboratory processes; more accurately capture laboratory and experiment data; more efficiently calculate, prepare, and disseminate analytical results; better aggregate and analyze laboratory data and information; increase throughput and productivity; and enhance regulatory compliance.<ref name="AstrixProgress22" /> Through regulatory, market, customer, and technological pressures, many laboratories have decided that increasingly digitizing the laboratory makes sense in its efforts towards compliance, competitiveness, relevancy, and efficiency.<ref name="AstrixProgress22" /><ref name="LiscouskiJust23">{{cite book |url=https://www.limswiki.org/index.php/LII:Justifying_LIMS_Acquisition_and_Deployment_within_Your_Organization/Introduction_to_LIMS_and_its_acquisition_and_deployment |title=Justifying LIMS Acquisition and Deployment within Your Organization |chapter=1. Introduction to LIMS and its acquisition and deployment |author=Liscouski, J. |editor=Douglas, S.E. |publisher=LIMSwiki |date=July 2023 |accessdate=13 March 2024}}</ref> A LIMS deployment primarily focuses on sample management, data acquisition, and reporting activities; however, its scope can expand much further depending on the scientific discipline or industry served. The following subsections examine these concepts further.


===Laboratory information management operations===
A 2019 survey by Europe's FAIRsFAIR found that researchers seeking and re-using relevant research software on the internet faced multiple challenges, including understanding and/or maintaining the necessary software environment and its dependencies, finding sufficient documentation, struggling with accessibility and licensing issues, having the time and skills to install and/or use the software, finding quality control of the source code lacking, and having an insufficient (or non-existent) software sustainability and management plan.<ref name="GruenpeterFAIRPlus20" /> These challenges highlight the importance of software to researchers and other stakeholders, and the roll FAIR has in better ensuring such software is findable, interoperable, and reusable, which in turn better ensures researchers' software-driven research is repeatable (by the same research team, with the same experimental setup), reproducible (by a different research team, with the same experimental setup), and replicable (by a different research team, with a different experimental setup).<ref name="GruenpeterFAIRPlus20" />
The LIMS is an evolving concept, with new features and functionality being added often. As laboratory demands change and technological progress continues, the functions of a LIMS will likely also change. Despite these changes, a LIMS tends to have a base set of functionality that defines it. That functionality can roughly be divided into five laboratory processing phases, with numerous software functions falling under each<ref name="MT5310">{{cite journal |title=Laboratory information management systems in the work of the analytic laboratory |journal=Measurement Techniques |author=Skobelev, D.O.; Zaytseva, T.M.; Kozlov, A.D. et al. |volume=53 |issue=10 |pages=1182–1189 |year=2011 |doi=10.1007/s11018-011-9638-7}}</ref>:


*the reception and log in of a sample and its associated customer data;
At this point, the topic of what "research software" represents must be addressed further, and, unsurprisingly, it's not straightforward. Ask 20 researchers what "research software" is, and you may get 20 different opinions. Some definitions can be more objectively viewed as too narrow, while others may be viewed as too broad, with some level of controversy inherent in any mutual discussion.<ref name="GruenpeterDefining21">{{Cite journal |last=Gruenpeter, Morane |last2=Katz, Daniel S. |last3=Lamprecht, Anna-Lena |last4=Honeyman, Tom |last5=Garijo, Daniel |last6=Struck, Alexander |last7=Niehues, Anna |last8=Martinez, Paula Andrea |last9=Castro, Leyla Jael |last10=Rabemanantsoa, Tovo |last11=Chue Hong, Neil P. |date=2021-09-13 |title=Defining Research Software: a controversial discussion |url=https://zenodo.org/record/5504016 |journal=Zenodo |doi=10.5281/zenodo.5504016}}</ref><ref name="JulichWhatIsRes24">{{cite web |url=https://www.fz-juelich.de/en/rse/about-rse/what-is-research-software |title=What is Research Software? |work=JuRSE, the Community of Practice for Research Software Engineering |publisher=Forschungszentrum Jülich |date=13 February 2024 |accessdate=30 April 2024}}</ref><ref name="vanNieuwpoortDefining24">{{Cite journal |last=van Nieuwpoort |first=Rob |last2=Katz |first2=Daniel S. |date=2023-03-14 |title=Defining the roles of research software |url=https://upstream.force11.org/defining-the-roles-of-research-software |language=en |doi=10.54900/9akm9y5-5ject5y}}</ref> In 2021, as part of the FAIRsFAIR initiative, Gruenpeter ''et al.'' made a good-faith effort to define "research software" with the feedback of multiple stakeholders. Their efforts resulted in this definition<ref name="GruenpeterDefining21" />:
*the assignment, scheduling, and tracking of the sample and the associated analytical workload;
*the processing and quality control associated with the sample and the utilized equipment and inventory;
*the storage of data associated with the sample analysis; and
*the inspection, approval, and compilation of the sample data for reporting and/or further analysis.


There are several pieces of core functionality associated with these laboratory processing phases that tend to appear in most LIMS.
<blockquote>Research software includes source code files, algorithms, scripts, computational workflows, and executables that were created during the research process, or for a research purpose. Software components (e.g., operating systems, libraries, dependencies, packages, scripts, etc.) that are used for research but were not created during, or with a clear research intent, should be considered "software [used] in research" and not research software. This differentiation may vary between disciplines. The minimal requirement for achieving computational reproducibility is that all the computational components (i.e., research software, software used in research, documentation, and hardware) used during the research are identified, described, and made accessible to the extent that is possible.</blockquote>


====Sample management====
Note that while the definition primarily recognizes software created during the research process, software created (whether by the research group, other open-source software developers outside the organization, or even commercial software developers) "for a research purpose" outside the actual research process is also recognized as research software. This notably can lead to disagreement about whether a proprietary, commercial spreadsheet or [[laboratory information management system]] (LIMS) offering that conducts analyses and visualizations of research data can genuinely be called research software, or simply classified as software used in research. van Nieuwpoort and Katz further elaborated on this concept, at least indirectly, by formally defining the roles of research software in 2023. Their definition of the various roles of research software—without using terms such as "open-source," "commercial," or "proprietary"—essentially further defined what research software is<ref name="vanNieuwpoortDefining24" />:
[[File:Lab worker with blood samples.jpg|thumb|260px|right|A lab worker matches blood samples to documents. With a LIMS, this sort of sample management is made more efficient.]]
The core function of LIMS has traditionally been and largely continues to be the management of samples.<ref name="LIMSHistory" /><ref name="KranjcIntro21">{{Citation |last=Kranjc |first=Tilen |date=2021-08-16 |editor-last=Zupancic |editor-first=Klemen |editor2-last=Pavlek |editor2-first=Tea |editor3-last=Erjavec |editor3-first=Jana |title=Introduction to Laboratory Software Solutions and Differences Between Them |url=https://onlinelibrary.wiley.com/doi/10.1002/9783527825042.ch3 |work=Digital Transformation of the Laboratory |language=en |edition=1 |publisher=Wiley |pages=75–84 |doi=10.1002/9783527825042.ch3 |isbn=978-3-527-34719-3 |accessdate=2024-03-12}}</ref> This typically is initiated when a sample is received in the laboratory, at which point the sample will be registered in the LIMS. This registration process may involve [[Accessioning (medical)|accessioning]] the sample and producing [[Barcode|barcodes]] to affix to the sample container. Various other parameters, such as clinical or phenotypic [[information]] corresponding with the sample, are also often recorded.<ref name="KranjcIntro21" /> The LIMS can then track a sample's progress throughout the lab and its workflow. In many cases, location tracking can be quite granular, down to a particular freezer location, even down to the level of shelf, rack, box, row, and column. Beyond location, other aspects of and actions upon the sample can be tracked and time-stamped, including freeze and thaw cycles that a sample undergoes, [[Aliquot|aliquoting]] of the sample, and more.


Modern LIMS have implemented extensive configurability, as each laboratory's needs for tracking additional data points can vary widely. LIMS vendors cannot typically make assumptions about what these data tracking needs are, and therefore vendors often create LIMS that are adaptable to individual environments. This typically involves the inclusion of workflow management tools in the LIMS. Users may also have regulatory concerns to comply with such as [[CLIA]], [[HIPAA]], [[21 CFR Part 11]], good laboratory practice (GLP), and FDA specifications, affecting certain aspects of sample management in a LIMS solution.<ref name="KranjcIntro21" /><ref name="RegCompLIMS">{{cite web |url=https://www.designworldonline.com/Regulatory-compliance-drives-LIMS/ |title=Regulatory compliance drives LIMS |author=Zipp, K. |work=Design World |publisher=WTWH Media, LLC |date=21 February 2007 |accessdate=12 March 2024}}</ref><ref name="BoyarLab21">{{Citation |last=Boyar |first=Kyle |last2=Pham |first2=Andrew |last3=Swantek |first3=Shannon |last4=Ward |first4=Gary |last5=Herman |first5=Gary |date=2021 |editor-last=Opie |editor-first=Shaun R. |title=Laboratory Information Management Systems (LIMS) |url=http://link.springer.com/10.1007/978-3-030-62716-4_7 |work=Cannabis Laboratory Fundamentals |language=en |publisher=Springer International Publishing |place=Cham |pages=131–151 |doi=10.1007/978-3-030-62716-4_7 |isbn=978-3-030-62715-7 |accessdate=2024-03-12}}</ref><ref name="FamiliLab22">{{Citation |last=Famili |first=Parsa |last2=Cleary |first2=Susan |date=2022-03-09 |editor-last=Huynh‐Ba |editor-first=Kim |title=Laboratory Information Management System (LIMS) and Electronic Data |url=https://onlinelibrary.wiley.com/doi/10.1002/9781119680475.ch10 |work=Analytical Testing for the Pharmaceutical GMP Laboratory |language=en |edition=1 |publisher=Wiley |pages=345–373 |doi=10.1002/9781119680475.ch10 |isbn=978-1-119-12091-9 |accessdate=2024-03-12}}</ref> In the end, an analytical lab's deliverables are the results of its analyses of samples and specimens; it's imperative they are timely, accurate, and of good provenance. At the core of any modern sample management activities is the concept of "[[data integrity]]", and a LIMS' ability to track sample-related data and metadata at every step of the laboratory workflow from the point of origin (thanks to instrument integration functionality<ref name="KranjcIntro21" />; see next subsection), all while using [[audit trail]] and [[electronic signature]] functionality, positively lends to a lab's overall approach to data integrity and producing accurate, defensible results.<ref name="FamiliLab22" /><ref name="McDowallHowCan16">{{cite journal |url=https://www.chromatographyonline.com/view/how-can-lims-help-ensure-data-integrity |title=How Can LIMS Help Ensure Data Integrity? |author=McDowall, R.D. |journal=LCGC Europe |volume=29 |issue=6 |pages=310–16 |year=2016 |accessdate=12 March 2024}}</ref>
*Research software is a component of our instruments.
*Research software is the instrument.
*Research software analyzes research data.
*Research software presents research results.
*Research software assembles or integrates existing components into a working whole.
*Research software is infrastructure or an underlying tool.
*Research software facilitates distinctively research-oriented collaboration.


====Instrument and application integration====
When considering these definitions<ref name="GruenpeterDefining21" /><ref name="vanNieuwpoortDefining24" /> of research software and their adoption by other entities<ref name="F1000Open24">{{cite web |url=https://www.f1000.com/resources-for-researchers/open-research/open-source-software-code/ |title=Open source software and code |publisher=F1000 Research Ltd |date=2024 |accessdate=30 April 2024}}</ref>, it would appear that at least in part some [[laboratory informatics]] software—whether open-source or commercially proprietary—fills these roles in academic, military, and industry research laboratories of many types. In particular, [[electronic laboratory notebook]]s (ELNs) like open-source [[Jupyter Notebook]] or proprietary ELNs from commercial software developers fill the role of analyzing and visualizing research data, including developing molecular models for new promising research routes.<ref name="vanNieuwpoortDefining24" /> Even more advanced LIMS solutions that go beyond simply collating, auditing, securing, and reporting analytical results could conceivably fall under the umbrella of research software, particularly if many of the analytical, integration, and collaboration tools required in modern research facilities are included in the LIMS.
Modern LIMS offer integration with laboratory instruments, a desirable feature for data integrity purposes.<ref name="KranjcIntro21" /> This used to be a costly and time-consuming process<ref name="Lanewala2024LIMS24" /><ref name="John3504HL7_11">{{cite web |url=https://community.spiceworks.com/topic/175107-hl7-interface-cost-and-maintenance |title=HL7 Interface cost and maintenance |author=John3504 |work=Spiceworks |date=07 December 2011 |accessdate=12 March 2024}}</ref><ref name="MLOStaffInterf12">{{cite web |url=https://www.mlo-online.com/home/article/13004490/interfacing-the-lis |title=Interfacing the LIS |author=MLO Staff |work=Medical Laboratory Observer |date=01 August 2012 |accessdate=12 March 2024}}</ref><ref name="DuckworthITIn">{{cite web |url=https://www.laboratorynetwork.com/doc/it-in-the-lab-the-instrument-interface-revisi-0002 |title=IT in the Lab: The Instrument Interface... Revisited |author=Duckworth, J. |work=Laboratory Network |accessdate=28 February 2024}}</ref>, setting up a control file on an instrument-by-instrument basis, which would "feed" into the instrument and direct its operation on some physical item such as a sample tube or sample plate. The LIMS would then import instrument results files back into the system and extract data for quality control assessment of the operation on the sample. The rise of modular, pre-configured [[middleware]] solutions that can from the start interface a series of device and device types to a LIMS more efficiently has in small part lessened this burden for LIMS users, however.<ref name="Lanewala2024LIMS24" /><ref name="MLOStaffInterf12" /> In all cases, the LIMS may also limit access to that instrument data fed into the system based on chain of custody assignments or other security features if need be.


In addition, a LIMS typically allows for the import and management of raw assay data results.<ref name="LBAssays">{{cite book |title=Ligand-Binding Assays: Development, Validation, and Implementation in the Drug Development Arena |author=Khan, Masood N.; Findlay, John W. |chapter=11.6 Integration: Tying It All Together |year=2009 |pages=324 |publisher=John Wiley & Sons |url=https://books.google.com/books?id=QzM0LUMfdAkC |isbn=0470041382 |accessdate=21 March 2020}}</ref> Modern targeted assays such as qPCR and deep [[sequencing]] can produce tens of thousands of data points per sample, all while the qPCR instrument is difficult itself to directly interface with the LIMS.<ref name="KranjcIntro21" /> Furthermore, in the case of drug and diagnostic development, a dozen or more assays may be run for any given sample. As such, the LIMS ideally will still provide a means to import raw data files extracted from instruments like qPCR even if the instrument itself can't be directly interfaced. However, in order to track and make usable this imported data, a LIMS solution needs to be adaptable to many different assay formats at both the data layer and import creation layer, while maintaining a high level of overall performance.
Ultimately, assuming that some laboratory informatics software can be considered research software and not just "software used in research," it's tough not to arrive at some deeper implications of research organizations' increasing need for FAIR data objects and software, particularly for laboratory informatics software and the developers of it.


Increasingly, a LIMS also provides the ability to integrate with other third-party applications such as ELNs, [[enterprise resource planning]] (ERP) systems, or regulatory compliance systems (such as [[Seed-to-sale|seed-to-sale]] reporting systems for [[wikipedia:Cannabis|cannabis]] testing).<ref name="KranjcIntro21" /><ref name="CSols10Ways17">{{cite web |url=https://www.csolsinc.com/blog/10-ways-lims-can-automate-lab/ |title=10 Ways LIMS Can Automate Your Lab |publisher=CSols, Inc |date=09 February 2017 |accessdate=12 March 2024}}</ref><ref name="AudinoManaging18">{{cite web |url=https://cannabisindustryjournal.com/feature_article/managing-cannabis-testing-lab-workflows-using-lims/ |title=Managing Cannabis Testing Lab Workflows using LIMS |author=Audino, S. |work=Cannabis Industry Journal |date=07 February 2018 |accessdate=12 March 2024}}</ref> This integration is typically achieved through the use of an [[application programming interface]] (API)<ref name="CSols10Ways17" /><ref name="AudinoManaging18" /><ref name="BerezinTenSimp23">{{Cite journal |last=Berezin |first=Casey-Tyler |last2=Aguilera |first2=Luis U. |last3=Billerbeck |first3=Sonja |last4=Bourne |first4=Philip E. |last5=Densmore |first5=Douglas |last6=Freemont |first6=Paul |last7=Gorochowski |first7=Thomas E. |last8=Hernandez |first8=Sarah I. |last9=Hillson |first9=Nathan J. |last10=King |first10=Connor R. |last11=Köpke |first11=Michael |date=2023-12-07 |editor-last=Markel |editor-first=Scott |title=Ten simple rules for managing laboratory information |url=https://dx.plos.org/10.1371/journal.pcbi.1011652 |journal=PLOS Computational Biology |language=en |volume=19 |issue=12 |pages=e1011652 |doi=10.1371/journal.pcbi.1011652 |issn=1553-7358 |pmc=PMC10703290 |pmid=38060459}}</ref>, code which serves as an interface between different software programs and databases, and facilitates their interactions.
==Implications of the FAIR concept to laboratory informatics software==
===The global FAIR initiative affects, and even benefits, commercial laboratory informatics research software developers as much as it does academic and institutional ones===
To be clear, there is undoubtedly a difference in the software development approach of "homegrown" research software by academics and institutions, and the more streamlined and experienced approach of commercial software development houses as applied to research software. Moynihan of Invenia Technical Computing described the difference in software development approaches thusly in 2020, while discussing the concept of "research software engineering"<ref name="MoynihanTheHitch20">{{cite web |url=https://invenia.github.io/blog/2020/07/07/software-engineering/ |title=The Hitchhiker’s Guide to Research Software Engineering: From PhD to RSE |author=Moynihan, G. |work=Invenia Blog |publisher=Invenia Technical Computing Corporation |date=07 July 2020}}</ref>:


====Electronic data exchange====
<blockquote>Since the environment and incentives around building academic research software are very different to those of industry, the workflows around the former are, in general, not guided by the same engineering practices that are valued in the latter. That is to say: there is a difference between what is important in writing software for research, and for a user-focused software product. Academic research software prioritizes scientific correctness and flexibility to experiment above all else in pursuit of the researchers’ end product: published papers. Industry software, on the other hand, prioritizes maintainability, robustness, and testing, as the software (generally speaking) is the product. However, the two tracks share many common goals as well, such as catering to “users” [and] emphasizing performance and reproducibility, but most importantly both ventures are collaborative. Arguably then, both sets of principles are needed to write and maintain high-quality research software.</blockquote>
The exponentially growing volume of data created in laboratories, coupled with increased business demands and focus on profitability, have pushed LIMS vendors to increase attention to how their LIMS handles the electronic exchange of data with other systems and instruments. The effectiveness of this data exchange is highly important to regulated industries that regularly report to an authority, as found with cannabis testing and some U.S. states' reporting requirements<ref name="AudinoManaging18" />, as well as clinical labs reporting to state- and federal-based public health agencies.<ref>{{Cite journal |last=Rajamani |first=Sripriya |last2=Kayser |first2=Ann |last3=Emerson |first3=Emily |last4=Solarz |first4=Sarah |date=2018-09-21 |title=Evaluation of Data Exchange Process for Interoperability and Impact on Electronic Laboratory Reporting Quality to a State Public Health Agency |url=https://journals.uic.edu/ojs/index.php/ojphi/article/view/9317 |journal=Online Journal of Public Health Informatics |volume=10 |issue=2 |doi=10.5210/ojphi.v10i2.9317 |issn=1947-2579 |pmc=PMC6194099 |pmid=30349622}}</ref> (Many labs' electronic systems' ability to exchange data with public health agencies was put to the test during the height of the [[COVID-19]] [[pandemic]].<ref name="DouglasWorkflow21">{{cite book |url=https://www.limswiki.org/index.php/LII:COVID-19_Testing,_Reporting,_and_Information_Management_in_the_Laboratory/Workflow_and_information_management_for_COVID-19_(and_other_respiratory_diseases) |title=COVID-19 Testing, Reporting, and Information Management in the Laboratory |chapter=4. Workflow and information management for COVID-19 (and other respiratory diseases) |author=Douglas, S.E. |publisher=LIMSwiki |edition=Fall 2021 |date=September 2021 |accessdate=12 March 2024}}</ref> In some cases, academic clinical research labs with the means to test patients using their qPCR devices simply couldn't exchange data with health systems' [[electronic health records]] [EHRs], which ultimately excluded those labs from assisting with COVID-19 testing.<ref name="MaxmenThousands20">{{cite journal |title=Thousands of coronavirus tests are going unused in US labs |journal=Nature |author=Maxmen, A. |volume=580 |issue=7803 |pages=312–13 |year=2020 |doi=10.1038/d41586-020-01068-3 |pmid=32273619}}</ref>)


In particular, attention must be paid to how an instrument's input and output data is managed, how remote sample collection data is imported and exported, and how mobile and other third-party applications integrate with the LIMS. The successful transfer of data files in a wide variety of formats (including interoperable nonproprietary file types for better meeting the FAIR principles of making data and information more findable, accessible, interoperable, and reusable<ref name="BerezinTenSimp23" />), while maintaining the associated metadata and keeping it secure, is paramount. Historically speaking, the transition "from proprietary databases to standardized database management systems such as Oracle ... and SQL" has had significant impact on how data is managed and exchanged in laboratories<ref name="WoodCompLabInfo">{{cite web |url=https://www.it.uu.se/edu/course/homepage/lims/vt12/ComprehensiveLaboratoryInformatics.pdf |archiveurl=https://web.archive.org/web/20170825181932/https://www.it.uu.se/edu/course/homepage/lims/vt12/ComprehensiveLaboratoryInformatics.pdf |format=PDF |title=Comprehensive Laboratory Informatics: A Multilayer Approach |author=Wood, S. |work=American Laboratory |page=1 |date=September 2007 |archivedate=25 August 2017 |accessdate=12 March 2024}}</ref>, culminating today in cloud-based relational and NOSQL databases that can be set up, operated, and scaled with relative ease.<ref name="AWSAmazonRDS">{{cite web |url=https://aws.amazon.com/rds/ |title=Amazon Relational Database Service (RDS) |publisher=Amazon Web Services, Inc |accessdate=12 March 2024}}</ref><ref name="LardinoisGoogle17">{{cite web |url=https://techcrunch.com/2017/02/14/google-launches-cloud-spanner-a-new-globally-distributed-database-service/ |title=Google launches Cloud Spanner, its new globally distributed relational database service |author=Lardionois, F. |work=TechCrunch |publisher=Oath, Inc |date=14 February 2017 |accessdate=12 March 2024}}</ref>
This brings us to our first point: the application of small-scale, FAIR-driven academic research software engineering practices and elements to the larger development of more commercial laboratory informatics software, and vice versa with the application of commercial-scale development practices to small FAIR-focused academic and institutional research software engineering efforts, has the potential to help better support all research laboratories using both independently-developed and commercial research software.  


====Additional functions====
The concept of the research software engineer (RSE) began to take full form in 2012, and since then universities and institutions of many types have formally developed their own RSE groups and academic programs.<ref name="WoolstonWhySci22">{{Cite journal |last=Woolston |first=Chris |date=2022-05-31 |title=Why science needs more research software engineers |url=https://www.nature.com/articles/d41586-022-01516-2 |journal=Nature |language=en |pages=d41586–022–01516-2 |doi=10.1038/d41586-022-01516-2 |issn=0028-0836}}</ref><ref name="KITRSE@KIT24">{{cite web |url=https://www.rse-community.kit.edu/index.php |title=RSE@KIT |publisher=Karlsruhe Institute of Technology |date=20 February 2024 |accessdate=01 May 2024}}</ref><ref name="PUPurdueCenter">{{cite web |url=https://www.rcac.purdue.edu/rse |title=Purdue Center for Research Software Engineering |publisher=Purdue University |date=2024 |accessdate=01 May 2024}}</ref> RSEs range from pure software developers with little knowledge of a given research discipline, to scientific researchers just beginning to learn how to develop software for their research project(s). While in the past, broadly speaking, researchers often cobbled together research software with less a focus on quality and reproducibility and more on getting their research published, today's push for FAIR data and software by academic journals, institutions, and other researchers seeking to collaborate has placed a much greater focus on the concept of "better software, better research."<ref name="WoolstonWhySci22" /><ref name="CohenTheFour21">{{Cite journal |last=Cohen |first=Jeremy |last2=Katz |first2=Daniel S. |last3=Barker |first3=Michelle |last4=Chue Hong |first4=Neil |last5=Haines |first5=Robert |last6=Jay |first6=Caroline |date=2021-01 |title=The Four Pillars of Research Software Engineering |url=https://ieeexplore.ieee.org/document/8994167/ |journal=IEEE Software |volume=38 |issue=1 |pages=97–105 |doi=10.1109/MS.2020.2973362 |issn=0740-7459}}</ref> Elaborating on that concept, Cohen ''et al.'' add that "ultimately, good research software can make the difference between valid, sustainable, reproducible research outputs and short-lived, potentially unreliable or erroneous outputs."<ref name="CohenTheFour21" />
In addition to the key functions of sample management, instrument and application integration, and electronic data exchange, there are numerous additional laboratory-based operations that can be managed in a LIMS. This includes but is not limited to<ref name="ASTM_E1578">{{cite web |url=https://www.astm.org/e1578-18.html |title=ASTM E1578-18 Standard Guide for Laboratory Informatics |publisher=ASTM International |date=23 August 2019 |accessdate=12 March 2024}}</ref><ref name="DouglasKeyLIMSFood22">{{cite web |url=https://www.limswiki.org/index.php/LIMS_Q%26A:What_are_the_key_elements_of_a_LIMS_for_food_and_beverage_testing%3F |title=LIMS Q&A:What are the key elements of a LIMS for food and beverage testing? |author=Douglas, S.E. |work=LIMSwiki |date=September 2022 |accessdate=12 March 2024}}</ref><ref name="DouglasLIMSpec22">{{cite web |url=https://www.limswiki.org/index.php/LII:LIMSpec_2022_R2 |title=LII:LIMSpec 2022 R2 |author=Douglas, S.E. |work=LIMSwiki |date=December 2022 |accessdate=12 March 2024}}</ref><ref name="DouglasWhatKeyISO23">{{cite web |url=https://www.limswiki.org/index.php/LIMS_Q%26A:What_are_the_key_elements_of_a_LIMS_to_better_comply_with_ISO/IEC_17025%3F |title=LIMS Q&A:What are the key elements of a LIMS to better comply with ISO/IEC 17025? |author=Douglas, S.E. |work=LIMSwiki |date=January 2023 |accessdate=12 March 2024}}</ref>:


'''Test, sample, and result management'''
The concept of [[software quality management]] (SQM) has traditionally not been lost on professional, commercial software development businesses. Good SQM practices have been less prevalent in homegrown research software development; however, the expanded adoption of FAIR data and FAIR software approaches has shifted the focus on to the repeatability, reproducibility, and interoperability of research results and data produced by a more sustainable research software. The adoption of FAIR by academic and institutional research labs not only brings commercial SQM and other software development approaches into their workflow, but also gives commercial laboratory informatics software developers an opportunity to embrace many aspects of the FAIR approach to laboratory research practices, including lessons learned and development practices from the growing number of RSEs. This doesn't mean commercial developers are going to suddenly take an open-source approach to their code, and it doesn't mean academic and institutional research labs are going to give up the benefits of the open-source paradigm as applied to research software.<ref>{{Cite journal |last=Hasselbring |first=Wilhelm |last2=Carr |first2=Leslie |last3=Hettrick |first3=Simon |last4=Packer |first4=Heather |last5=Tiropanis |first5=Thanassis |date=2020-02-25 |title=From FAIR research data toward FAIR and open research software |url=https://www.degruyter.com/document/doi/10.1515/itit-2019-0040/html |journal=it - Information Technology |language=en |volume=62 |issue=1 |pages=39–47 |doi=10.1515/itit-2019-0040 |issn=2196-7032}}</ref> However, as Moynihan noted, both research software development paradigms stand to gain from the shift to more FAIR data and software.<ref name="MoynihanTheHitch20" /> Additionally, if commercial laboratory informatics vendors want to continue to competitively market relevant and sustainable research software to research labs, they frankly have little choice but to commit extra resources to learning about the application of FAIR principles to their offerings tailored to those labs.


*End-to-end sample and inventory management and tracking
===The focus on data types and metadata within the scope of FAIR is shifting how laboratory informatics software developers and RSEs make their research software and choose their database approaches===
*Complete capture of a registered sample's data and metadata
Close to the core of any deep discussion of the FAIR data principles are the concepts of data models, data types, [[metadata]], and persistent unique identifiers (PIDs). Making research objects more findable, accessible, interoperable, and reusable is no easy task when data types and approaches to metadata assignment (if there even is such an approach) are widely differing and inconsistent. Metadata is a means for better storing and characterizing research objects for the purposes of ensuring provenance and reproducibility of those research objects.<ref name="GhiringhelliShared23">{{Cite journal |last=Ghiringhelli |first=Luca M. |last2=Baldauf |first2=Carsten |last3=Bereau |first3=Tristan |last4=Brockhauser |first4=Sandor |last5=Carbogno |first5=Christian |last6=Chamanara |first6=Javad |last7=Cozzini |first7=Stefano |last8=Curtarolo |first8=Stefano |last9=Draxl |first9=Claudia |last10=Dwaraknath |first10=Shyam |last11=Fekete |first11=Ádám |date=2023-09-14 |title=Shared metadata for data-centric materials science |url=https://www.nature.com/articles/s41597-023-02501-8 |journal=Scientific Data |language=en |volume=10 |issue=1 |pages=626 |doi=10.1038/s41597-023-02501-8 |issn=2052-4463 |pmc=PMC10502089 |pmid=37709811}}</ref><ref name="FirschenAgile22">{{Cite journal |last=Fitschen |first=Timm |last2=tom Wörden |first2=Henrik |last3=Schlemmer |first3=Alexander |last4=Spreckelsen |first4=Florian |last5=Hornung |first5=Daniel |date=2022-10-12 |title=Agile Research Data Management with FDOs using LinkAhead |url=https://riojournal.com/article/96075/ |journal=Research Ideas and Outcomes |volume=8 |pages=e96075 |doi=10.3897/rio.8.e96075 |issn=2367-7163}}</ref> This means as early as possible implementing a software-based approach that is FAIR-driven, capturing FAIR metadata using flexible domain-driven [[Ontology (information science)|ontologies]] (i.e., controlled vocabularies) at the source and cleaning up old research objects that aren't FAIR-ready while also limiting hindrances to research processes as much as possible.<ref name="FirschenAgile22" /> And that approach must value the importance of metadata and PIDs. As Weigel ''et al.'' note in a discussion on making laboratory data and workflows more machine-findable: "Metadata capture must be highly automated and reliable, both in terms of technical reliability and ensured metadata quality. This requires an approach that may be very different from established procedures."<ref>{{Cite journal |last=Weigel |first=Tobias |last2=Schwardmann |first2=Ulrich |last3=Klump |first3=Jens |last4=Bendoukha |first4=Sofiane |last5=Quick |first5=Robert |date=2020-01 |title=Making Data and Workflows Findable for Machines |url=https://direct.mit.edu/dint/article/2/1-2/40-46/9994 |journal=Data Intelligence |language=en |volume=2 |issue=1-2 |pages=40–46 |doi=10.1162/dint_a_00026 |issn=2641-435X}}</ref> Enter non-relational RDF [[knowledge graph]] [[database]]s.
*Unique sample identifiers
*Sample batching
*Free-form reception-based sample data
*Barcode and RFID support
*Pre-defined and configurable common and industry-specific sample types, tests, methods, and protocols
*Pre-defined and configurable industry-specific workflows
*Robust sampling and test method development
*Configurable screens and data fields
*Specification management
*Test, sampling, instrument, etc. scheduling and assignment
*Test requesting
*Data import and export
*Robust query tools
*Analytical tools, including data visualization, statistical analysis, and data mining tools
*Project management
*Investigation management
*Facility and sampling site management
*Storage management and monitoring


'''Quality, security, and compliance'''
This brings us to our second point: given the importance of metadata and PIDs to FAIRifying research objects (and even research software), established, more traditional research software development methods using common relational databases may not be enough, even for commercial laboratory informatics software developers. Non-relational [[Resource Description Framework]] (RDF) knowledge graph databases used in FAIR-driven, well-designed laboratory informatics software help make research objects more FAIR for all research labs.


*Quality assurance / quality control mechanisms
Research objects can take many forms (i.e., data types), making the storage and management of those objects challenging, particularly in research settings with great diversity of data, as with materials research. Some have approached this challenge by combining different database and systems technologies that are best suited for each data type.<ref name="AggourSemantics24">{{Cite journal |last=Aggour |first=Kareem S. |last2=Kumar |first2=Vijay S. |last3=Gupta |first3=Vipul K. |last4=Gabaldon |first4=Alfredo |last5=Cuddihy |first5=Paul |last6=Mulwad |first6=Varish |date=2024-04-09 |title=Semantics-Enabled Data Federation: Bringing Materials Scientists Closer to FAIR Data |url=https://link.springer.com/10.1007/s40192-024-00348-4 |journal=Integrating Materials and Manufacturing Innovation |language=en |doi=10.1007/s40192-024-00348-4 |issn=2193-9764}}</ref> However, while query performance and storage footprint improves with this approach, data across the different storage mechanisms typically remains unlinked and non-compliant with FAIR principles. Here, either a full RDF knowledge graph database or similar integration layer is required to better make the research objects more interoperable and reusable, whether it's materials records or specimen data.<ref name="AggourSemantics24" /><ref name="GrobeFromData19">{{Cite journal |last=Grobe |first=Peter |last2=Baum |first2=Roman |last3=Bhatty |first3=Philipp |last4=Köhler |first4=Christian |last5=Meid |first5=Sandra |last6=Quast |first6=Björn |last7=Vogt |first7=Lars |date=2019-06-26 |title=From Data to Knowledge: A semantic knowledge graph application for curating specimen data |url=https://biss.pensoft.net/article/37412/ |journal=Biodiversity Information Science and Standards |language=en |volume=3 |pages=e37412 |doi=10.3897/biss.3.37412 |issn=2535-0897}}</ref>
*Multi-level review of test results
*Validation of sampling and test methods
*Audit trails and chain of custody support
*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
*Incident, nonconformance, and deviation notification, tracking, and management
*Statistical trending and control charts
*Internal and external audit management
*Secure backup and retrieval
*Facility monitoring
*Environmental monitoring
*Data retention and encryption
*Robust system security
*LIMS validation
*Secure granular access
*Logical and physical access control
*Electronic signature support
*Status updates and alerts


'''Operations management and reporting'''
It is beyond the scope of this Q&A article to discuss RDF knowledge graph databases at length. (For a deeper dive on this topic, see Rocca-Serra ''et al.'' and the FAIR Cookbook.<ref name="Rocca-SerraFAIRCook22">{{Cite book |last=Rocca-Serra, Philippe |last2=Sansone, Susanna-Assunta |last3=Gu, Wei |last4=Welter, Danielle |last5=Abbassi Daloii, Tooba |last6=Portell-Silva, Laura |date=2022-06-30 |title=D2.1 FAIR Cookbook |url=https://zenodo.org/record/6783564 |chapter=FAIR and Knowledge graphs |doi=10.5281/ZENODO.6783564}}</ref>) However, know that the primary strength of these databases to FAIRification of research objects is their ability to provide [[Semantics|semantic]] transparency (i.e., provide a framework for better understanding and reusing the greater research object through basic examination of the relationships of its associated metadata and their constituents), making these objects more easily accessible, interoperable, and machine-readable.<ref name="AggourSemantics24" /> The resulting knowledge graphs, with their "subject-property-object" syntax and PIDs or uniform resource identifiers (URIs) helping to link data, metadata, ontology classes, and more, can be interpreted, searched, and linked by machines, and made human-readable, resulting in better research through derivation of new knowledge from the existing research objects. The end result is a representation of heterogeneous data and metadata that complies with the FAIR guiding principles.<ref name="AggourSemantics24" /><ref name="GrobeFromData19" /><ref name="Rocca-SerraFAIRCook22" /><ref name="TomlinsonRDF23">{{cite web |url=https://21624527.fs1.hubspotusercontent-na1.net/hubfs/21624527/Resources/RDF%20Knowledge%20Graph%20Databases%20White%20Paper.pdf |format=PDF |title=RDF Knowledge Graph Databases: A Better Choice for Life Science Lab Software |author=Tomlinson, E. |publisher=Semaphore Solutions, Inc |date=28 July 2023 |accessdate=01 May 2024}}</ref><ref name="DeagenFAIRAnd22">{{Cite journal |last=Deagen |first=Michael E. |last2=McCusker |first2=Jamie P. |last3=Fateye |first3=Tolulomo |last4=Stouffer |first4=Samuel |last5=Brinson |first5=L. Cate |last6=McGuinness |first6=Deborah L. |last7=Schadler |first7=Linda S. |date=2022-05-27 |title=FAIR and Interactive Data Graphics from a Scientific Knowledge Graph |url=https://www.nature.com/articles/s41597-022-01352-z |journal=Scientific Data |language=en |volume=9 |issue=1 |pages=239 |doi=10.1038/s41597-022-01352-z |issn=2052-4463 |pmc=PMC9142568 |pmid=35624233}}</ref><ref>{{Cite journal |last=Brandizi |first=Marco |last2=Singh |first2=Ajit |last3=Rawlings |first3=Christopher |last4=Hassani-Pak |first4=Keywan |date=2018-09-25 |title=Towards FAIRer Biological Knowledge Networks Using a Hybrid Linked Data and Graph Database Approach |url=https://www.degruyter.com/document/doi/10.1515/jib-2018-0023/html |journal=Journal of Integrative Bioinformatics |language=en |volume=15 |issue=3 |pages=20180023 |doi=10.1515/jib-2018-0023 |issn=1613-4516 |pmc=PMC6340125 |pmid=30085931}}</ref> This concept can even be extended to ''post factum'' visualizations of the knowledge graph data<ref name="DeagenFAIRAnd22" />, as well as the FAIR management of computational laboratory [[workflow]]s.<ref>{{Cite journal |last=de Visser |first=Casper |last2=Johansson |first2=Lennart F. |last3=Kulkarni |first3=Purva |last4=Mei |first4=Hailiang |last5=Neerincx |first5=Pieter |last6=Joeri van der Velde |first6=K. |last7=Horvatovich |first7=Péter |last8=van Gool |first8=Alain J. |last9=Swertz |first9=Morris A. |last10=Hoen |first10=Peter A. C. ‘t |last11=Niehues |first11=Anna |date=2023-09-28 |editor-last=Palagi |editor-first=Patricia M. |title=Ten quick tips for building FAIR workflows |url=https://dx.plos.org/10.1371/journal.pcbi.1011369 |journal=PLOS Computational Biology |language=en |volume=19 |issue=9 |pages=e1011369 |doi=10.1371/journal.pcbi.1011369 |issn=1553-7358 |pmc=PMC10538699 |pmid=37768885}}</ref>


*Document and image management, with versioning and release controls
While rare, some commercial laboratory informatics vendors like Semaphore Solutions have already recognized the potential of RDF knowledge graph databases to FAIR-driven laboratory research, having implemented such structures into their offerings.<ref name="TomlinsonRDF23" /> (The use of knowledge graphs has already been demonstrated in academic research software, such as with the ELN tools developed by RSEs at the University of Rostock and University of Amsterdam.<ref>{{Cite journal |last=Schröder |first=Max |last2=Staehlke |first2=Susanne |last3=Groth |first3=Paul |last4=Nebe |first4=J. Barbara |last5=Spors |first5=Sascha |last6=Krüger |first6=Frank |date=2022-12 |title=Structure-based knowledge acquisition from electronic lab notebooks for research data provenance documentation |url=https://jbiomedsem.biomedcentral.com/articles/10.1186/s13326-021-00257-x |journal=Journal of Biomedical Semantics |language=en |volume=13 |issue=1 |pages=4 |doi=10.1186/s13326-021-00257-x |issn=2041-1480 |pmc=PMC8802522 |pmid=35101121}}</ref>) As noted in the prior point, it is potentially advantageous to not only laboratory informatics vendors to provide but also research labs to use relevant and sustainable research software that has the FAIR principles embedded in the software's design. Turning to knowledge graph databases is another example of keeping such software relevant and FAIR to research labs.
*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 importing and exporting of a variety of formats, including interoperable nonproprietary file types
*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
*Configurable dashboards for monitoring, by product, process, facility, etc.
*Industry-compliant reporting and labeling
*Email integration
*Instrument interfacing and data management
*Third-party software and database interfacing
*Supplier/vendor/customer management
*Integrated (or online) system help


===LIMS architecture and delivery methods===
===Applying FAIR-driven metadata schemes to laboratory informatics software development gives data a FAIRer chance at being ready for machine learning and artificial intelligence applications===
A LIMS has historically over many decades depended on a variety of architectures and distribution models for its implementation and use. As technology has changed, how a LIMS is installed, managed, and used has also changed with it. The following represents architectures which have been utilized at one point or another.
The third and final point for this Q&A article highlights another positive consequence of engineering laboratory informatics software with FAIR in mind: FAIRified research objects are much closer to being usable for the trending inclusion of [[machine learning]] (ML) and [[artificial intelligence]] (AI) tools in laboratory informatics platforms and other companion research software. By developing laboratory informatics software with a focus on FAIR-driven metadata and database schemes, not only are research objects more FAIR but also "cleaner" and more machine-ready for advanced analytical uses as with ML and AI.


====Thick-client====
To be sure, the FAIRness of any structured dataset alone is not enough to make it ready for ML and AI applications. Factors such as classification, completeness, context, correctness, duplicity, integrity, mislabeling, outliers, relevancy, sample size, and timeliness of the research object and its contents are also important to consider.<ref name="HinidumaDataRead24">{{Cite journal |last=Hiniduma |first=Kaveen |last2=Byna |first2=Suren |last3=Bez |first3=Jean Luca |date=2024 |title=Data Readiness for AI: A 360-Degree Survey |url=https://arxiv.org/abs/2404.05779 |journal=arXiv |doi=10.48550/ARXIV.2404.05779}}</ref><ref name="FletcherFAIRRe24">{{Cite journal |last=Fletcher |first=Lydia |date=2024-04-16 |others=The University Of Texas At Austin, The University Of Texas At Austin |title=FAIR Re-use: Implications for AI-Readiness |url=https://repositories.lib.utexas.edu/handle/2152/124873 |doi=10.26153/TSW/51475}}</ref> When those factors aren't appropriately addressed as part of a FAIRification effort towards AI readiness (as well as part of the development of research software of all types), research data and metadata have a higher likelihood of revealing themselves to be inconsistent. As such, searches and analytics using that data and metadata become muddled, and the ultimate ML or AI output will also be muddled (i.e., "garbage in, garbage out"). Whether retroactively updating existing research objects to a more FAIRified state or ensuring research objects (e.g., those originating in an ELN or LIMS) are more FAIR and AI-ready from the start, research software updating or generating those research objects has to address ontologies, data models, data types, identifiers, and more in a thorough yet flexible way.<ref name="OlsenEmbracing23">{{cite web |url=https://www.pharmasalmanac.com/articles/embracing-fair-data-on-the-path-to-ai-readiness |title=Embracing FAIR Data on the Path to AI-Readiness |author=Olsen, C. |work=Pharma's Almanac |date=01 September 2023 |accessdate=03 May 2024}}</ref>
A thick-client LIMS is a more traditional client/server architecture, with some of the system residing on the computer or workstation of the user (the client) and the rest on the server. The LIMS software is installed on the client computer, which does all of the data processing. Later it passes information to the server, which has the primary purpose of data storage. Most changes, upgrades, and other modifications will happen on the client side.  


This was one of the first architectures implemented into a LIMS, having the advantage of providing higher processing speeds (because processing is done on the client and not the server) and slightly more security (as access to the server data is limited only to those with client software). Additionally, thick-client systems have also provided more interactivity and customization, though often at a greater learning curve. The disadvantages of client-side LIMS include the need for more robust client computers and more time-consuming upgrades, as well as a lack of base functionality through a web browser. The thick-client LIMS can become web-enabled through an add-on component.<ref name="SciComp">{{cite web |url=https://www.scientificcomputing.com/article/2008/08/selecting-right-lims |archiveurl=https://web.archive.org/web/20160829104930/https://www.scientificcomputing.com/article/2008/08/selecting-right-lims |title=Selecting the Right LIMS: Critiquing technological strengths and limitations |author=O'Leary, K.M. |work=Scientific Computing |publisher=Advantage Business Media |date=11 August 2008 |archivedate=29 August 2016 |accessdate=12 March 2024}}</ref><ref name="LabVantageDifInTech">{{cite web |url=http://www.labvantage.com/resources/pdf/whitepapers/ThinClient1101JY21CYL.pdf |archiveurl=https://web.archive.org/web/20140227052508/http://www.labvantage.com/resources/pdf/whitepapers/ThinClient1101JY21CYL.pdf |format=PDF |title=How Differences in Technology Affect LIMS Functionality, Cost, & ROI |publisher=LabVantage Solutions, Inc |date=2011 |pages=2–3 |archivedate=27 February 2014 |accessdate=12 March 2024}}</ref>
Noting that Wilkinson ''et al.'' originally highlighted the importance of machine-readability of FAIR data, Huerta ''et al.'' add that that core principle of FAIRness "is synergistic with the rapid adoption and increased use of AI in research."<ref name="HuertaFAIRForAI23">{{Cite journal |last=Huerta |first=E. A. |last2=Blaiszik |first2=Ben |last3=Brinson |first3=L. Catherine |last4=Bouchard |first4=Kristofer E. |last5=Diaz |first5=Daniel |last6=Doglioni |first6=Caterina |last7=Duarte |first7=Javier M. |last8=Emani |first8=Murali |last9=Foster |first9=Ian |last10=Fox |first10=Geoffrey |last11=Harris |first11=Philip |date=2023-07-26 |title=FAIR for AI: An interdisciplinary and international community building perspective |url=https://www.nature.com/articles/s41597-023-02298-6 |journal=Scientific Data |language=en |volume=10 |issue=1 |pages=487 |doi=10.1038/s41597-023-02298-6 |issn=2052-4463 |pmc=PMC10372139 |pmid=37495591}}</ref> They go on to discuss the positive interactions of FAIR research objects with FAIR-driven, AI-based research. Among the benefits include<ref name="HuertaFAIRForAI23" />:


'''Web-enabled'''
*greater findability of FAIR research objects for further AI-driven scientific discovery;
*greater reproducibility of FAIR research objects and any AI models published with them;
*improved generalization of AI-driven medical research models when exposed to diverse and FAIR research objects;
*improved reporting of AI-driven research results using FAIRified research objects, lending further credibility to those results;
*more uniform comparison of AI models using well-defined hyperstructure and information training conditions from FAIRified research objects;
*more developed and interoperable "data e-infrastructure," which can further drive a more effective "AI services layer";
*reduced bias in AI-driven processes through the use of FAIR research objects and AI models; and
*improved surety of scientific correctness where reproducibility in AI-driven research can't be guaranteed.


A web-enabled LIMS architecture is essentially a thick-client architecture with an added web browser component. In this setup, the client-side software has additional functionality that allows users to interface with the software through their device's browser. This functionality is typically limited only to certain functions of the web client. The primary advantage of a web-enabled LIMS is the end-user can access data both on the client side and the server side of the configuration. As in a thick-client architecture, updates in the software must be propagated to every client machine. However, the added disadvantages of requiring always-on access to the host server and the need for cross-platform functionality mean that additional overhead costs may arise.<ref name="SciComp" /><ref name="LabVantageDifInTech" />
In the end, developers of research software (whether discipline-specific research software or broader laboratory informatics solutions) would be advised to keep in mind the growing trends of FAIR research, FAIR software, and ML- and AI-driven research, especially in the [[life sciences]], but also a variety of other fields.<ref name="HuertaFAIRForAI23" />


====Thin-client====
===Restricted clinical data and its FAIRification for greater research innovation===
[[File:Cloud computing.svg|right|thumb|360px|The concept of cloud computing is one of the most recent architecture and delivery models to affect LIMS.]]A thin-client LIMS is a more modern architecture which offers full application functionality accessed through a device's web browser. The actual LIMS software resides on a server (host) which feeds and processes information without saving it to the user's hard disk. Any necessary changes, upgrades, and other modifications are handled by the entity hosting the server-side LIMS software, meaning all end-users see all changes made. To this end, a true thin-client LIMS will leave no "footprint" on the client's computer, and only the integrity of the web browser need be maintained by the user. The advantages of this system include significantly lower cost of ownership and fewer network and client-side maintenance expenses. However, this architecture has the disadvantage of requiring real-time server access, a need for increased network throughput, and slightly less functionality. A sort of hybrid architecture that incorporates the features of thin-client browser usage with a thick client installation exists in the form of a web-based LIMS.<ref name="SciComp" /><ref name="LabVantageDifInTech" />
Broader discussion in the research community continues to occur in regards to how best to ethically make restricted or privacy-protected clinical data and information FAIR for greater innovation and, by extension, improved patient outcomes, particularly in the wake of the [[COVID-19]] [[pandemic]].<ref name="MaxwellFAIREthic23">{{Cite journal |last=Maxwell |first=Lauren |last2=Shreedhar |first2=Priya |last3=Dauga |first3=Delphine |last4=McQuilton |first4=Peter |last5=Terry |first5=Robert F |last6=Denisiuk |first6=Alisa |last7=Molnar-Gabor |first7=Fruzsina |last8=Saxena |first8=Abha |last9=Sansone |first9=Susanna-Assunta |date=2023-10 |title=FAIR, ethical, and coordinated data sharing for COVID-19 response: a scoping review and cross-sectional survey of COVID-19 data sharing platforms and registries |url=https://linkinghub.elsevier.com/retrieve/pii/S2589750023001292 |journal=The Lancet Digital Health |language=en |volume=5 |issue=10 |pages=e712–e736 |doi=10.1016/S2589-7500(23)00129-2 |pmc=PMC10552001 |pmid=37775189}}</ref><ref name="Queralt-RosinachApplying22">{{Cite journal |last=Queralt-Rosinach |first=Núria |last2=Kaliyaperumal |first2=Rajaram |last3=Bernabé |first3=César H. |last4=Long |first4=Qinqin |last5=Joosten |first5=Simone A. |last6=van der Wijk |first6=Henk Jan |last7=Flikkenschild |first7=Erik L.A. |last8=Burger |first8=Kees |last9=Jacobsen |first9=Annika |last10=Mons |first10=Barend |last11=Roos |first11=Marco |date=2022-12 |title=Applying the FAIR principles to data in a hospital: challenges and opportunities in a pandemic |url=https://jbiomedsem.biomedcentral.com/articles/10.1186/s13326-022-00263-7 |journal=Journal of Biomedical Semantics |language=en |volume=13 |issue=1 |pages=12 |doi=10.1186/s13326-022-00263-7 |issn=2041-1480 |pmc=PMC9036506 |pmid=35468846}}</ref><ref>{{Cite journal |last=Martínez-García |first=Alicia |last2=Alvarez-Romero |first2=Celia |last3=Román-Villarán |first3=Esther |last4=Bernabeu-Wittel |first4=Máximo |last5=Luis Parra-Calderón |first5=Carlos |date=2023-05 |title=FAIR principles to improve the impact on health research management outcomes |url=https://linkinghub.elsevier.com/retrieve/pii/S2405844023029407 |journal=Heliyon |language=en |volume=9 |issue=5 |pages=e15733 |doi=10.1016/j.heliyon.2023.e15733 |pmc=PMC10189186 |pmid=37205991}}</ref> (Note that while there are other types of restricted and privacy-protected data, this section will focus largely on clinical data and research objects as the most obvious type.)


Additionally, maintenance support and warranty (MSW) agreements are usually offered with thin-client installations. Pricing levels are typically based on a percentage of the license fee, with a standard level of service for 10 concurrent users being approximately 10 hours of support and additional customer service at a set per-hour rate. Though some may choose to opt out of an MSW after the first year, it's often more economical to continue the plan in order to receive updates to the LIMS, giving it a longer life span in the laboratory.
These efforts have usually revolved around pulling reusable clinical patient or research data from [[hospital information system]]s (HIS), [[electronic medical record]]s (EMRs), [[clinical trial management system]]s (CTMSs), and research databases (often relational in nature) that either contain de-identified data or can de-identify aspects of data and information before access and extraction. Sometimes that clinical data or research object may have already in part been FAIRified, but often it may not be. In all cases, the concepts of privacy, security, and anonymization come up as part of any desire to gain access to that clinical material. However, any FAIRified clinical data isn't necessarily readily open for access. As Snoeijer ''et al.'' note: "The authors of the FAIR principles, however, clearly indicate that 'accessible' does not mean open. It means that clarity and transparency is required around the conditions governing access and reuse."<ref name="SnoeijerProcess19">{{cite book |url=https://phuse.s3.eu-central-1.amazonaws.com/Archive/2019/Connect/EU/Amsterdam/PAP_SA04.pdf |format=PDF |chapter=Paper SA04 - Processing big data from multiple sources |title=Proceedings of PHUSE Connect EU 2019 |author=Snoeijer, B.; Pasapula, V.; Covucci, A. et al. |publisher=PHUSE Limited |year=2019 |accessdate=03 May 2024}}</ref>


'''Cloud and SaaS'''
This is being mentioned in the context of laboratory informatics applications for a couple of reasons. First, a well-designed commercial LIMS that supports clinical research laboratory workflows is already going to address privacy and security aspects, as part of the developer recognizing the need for those labs to adhere to regulations such as the [[Health Insurance Portability and Accountability Act]] (HIPAA) and comply with standards such as [[ISO 15189]]. However, such a system may not have been developed with FAIR data principles in mind, and any built-in metadata and ontology schemes may be insufficient for full FAIRification of laboratory-based clinical trial research objects. As Queralt-Rosinach ''et al.'' note, however, "interestingly, ontologies may also be used to describe data access restrictions to complement FAIR metadata with information that supports data safety and patient privacy."<ref name="Queralt-RosinachApplying22" /> Essentially, the authors are suggesting that while a HIS or LIS may have built-in access management tools, setting up ontologies and metadata mechanisms that link privacy aspects of a research object (e.g., "has consent form for," "is de-identified," etc.) to the object's metadata allows for even more flexible, FAIR-driven approaches to privacy and security. Research software developers creating such information management tools for the regulated clinical research space may want to apply FAIR concepts such as this to how access control and privacy restrictions are managed. This will inevitably mean any research objects exported with machine-readable privacy-concerning metadata will be more reusable in a way that still "supports data safety and patient privacy."<ref name="Queralt-RosinachApplying22" />


In the early 2010s, LIMS vendors began to rent hosted, thin-client solutions as "[[Software as a service|software as a service]]" (SaaS). These cloud-based solutions tended to be less configurable than on-premise solutions and were therefore considered for less demanding implementations such as laboratories with few users and limited sample processing volumes. However, cloud-based software has seen greater adoption as the technology has improved, and configurable LIMS for laboratory operations big and small have become a more realistic option.<ref name="KnippenbergMoving17" /><ref name="JoyceWhatYou17" /><ref name="AstrixProgress22" /><ref name="Lanewala2024LIMS24" /> For example, a June 2022 report published by Astrix Technology found that of life science organizations surveyed, 78 percent of them indicated they have adopted and used or plan to adopt and use cloud-based applications; of all respondents, 43 percent said they are taking a cloud-first or cloud-only approach to its laboratory applications.<ref name="AstrixProgress22" />
Second, a well-designed research software solution working with clinical data will provide not only support for open, community-supported data models and vocabularies for clinical data, but also standardized community-driven ontologies that are specifically developed for access control and privacy. Queralt-Rosinach ''et al.'' continue<ref name="Queralt-RosinachApplying22" />:


====Web-based====
<blockquote>Also, very important for accessibility and data privacy is that the digital objects ''per se'' can accommodate the criteria and protocols necessary to comply with regulatory and governance frameworks. Ontologies can aid in opening and protecting patient data by exposing logical definitions of data use conditions. Indeed, there are ontologies to define access and reuse conditions for patient data such as the Informed Consent Ontology (ICO), the Global Alliance for Genomics and Health Data Use Ontology (DUO) standard, and the Open Digital Rights Language (ODRL) vocabulary recommended by W3C.</blockquote>
Arguably one of the most confusing architectures, web-based LIMS architecture is a hybrid of the thick- and thin-client architectures. While much of the client-side work is done through a web browser, the LIMS also requires the additional support of Microsoft's .NET Framework technology installed on the client device. The end result is a process that is apparent to the end-user through the Microsoft-compatible web browser, but perhaps not so apparent as it runs thick-client-like processing in the background. In this case, web-based architecture has the advantage of providing more functionality through a more friendly web interface. The disadvantages of this setup are more sunk costs in system administration and support for Internet Explorer and .NET technologies, and reduced functionality on mobile platforms.<ref name="SciComp" /><ref name="LabVantageDifInTech" />


==The distinction between a LIMS and a LIS==
Also of note here is the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) and its OHDSI standardized vocabularies. In all these cases, a developer-driven approach to research software that incorporates community-driven standards that support FAIR principles is welcome. However, as Maxwell ''et al.'' noted in their ''Lancet'' review article in late 2023, "few platforms or registries applied community-developed standards for participant-level data, further restricting the interoperability of ... data-sharing initiatives [like FAIR]."<ref name="MaxwellFAIREthic23" /> As the FAIR principles continue to gain ground in clinical research and diagnostics settings, software developers will need to be more attuned to translating old ways of development to ones that incorporate FAIR data and software principles. Demand for FAIR data will only continue to grow, and any efforts to improve interoperability and reusability while honoring (and enhancing) privacy and security aspects of restricted data will be appreciated by clinical researchers. However, just as FAIR is not an overall goal for researchers, software built with FAIR principles in mind is not the end point of research organizations managing restricted and privacy-protected research objects. Ultimately, those organizations will have make other considerations about restricted data in the scope of FAIR, including addressing data management plans, data use agreements, disclosure review practices, and training as it applies to their research software and generated research objects.<ref>{{Cite journal |last=Jang |first=Joy Bohyun |last2=Pienta |first2=Amy |last3=Levenstein |first3=Margaret |last4=Saul |first4=Joe |date=2023-12-06 |title=Restricted data management: the current practice and the future |url=https://journalprivacyconfidentiality.org/index.php/jpc/article/view/844 |journal=Journal of Privacy and Confidentiality |volume=13 |issue=2 |doi=10.29012/jpc.844 |issn=2575-8527 |pmc=PMC10956935 |pmid=38515607}}</ref>
Historically, the LIMS and LIS have exhibited a few key differences, making them noticeably separate entities<ref name="StarlimsLimsLis">{{cite web |url=http://www.starlims.com/en-us/services-and-resources/resources/lis-vs-lims/ |archiveurl=https://web.archive.org/web/20140428060811/http://www.starlims.com/en-us/resources/white-papers/lis-vs-lims/ |title=Adding "Management" to Your LIS |publisher=STARLIMS Corporation |date=2012 |archivedate=28 April 2014 |accessdate=13 March 2024}}</ref>:


1. A LIMS traditionally has been designed to process and report data related to batches of samples from biology labs, water treatment facilities, drug trials, and other entities that handle complex batches of data. A LIS has been designed primarily for processing and reporting data related to individual patients in a clinical setting.<ref name="lislims1">{{cite web |url=http://labsoftnews.typepad.com/lab_soft_news/2008/11/liss-vs-limss-its-time-to-consider-merging-the-two-types-of-systems.html |title=LIS vs. LIMS: It's Time to Blend the Two Types of Lab Information Systems |author=Friedman, B. |work=Lab Soft News |date=04 November 2008 |accessdate=13 March 2024}}</ref><ref name="analytica">{{cite web |url=https://www.analytica-world.com/en/news/35566/lims-lis-market-and-poct-supplement.html |title=LIMS/LIS Market and POCT Supplement |work=analytica-world.com |date=20 February 2004 |accessdate=13 March 2024}}</ref>
==Conclusion==
Laboratory informatics developers will also need to remember that FAIRification of research in itself is not a goal for research laboratories; it is a continual process that recognizes improved scientific research and greater innovation as a more likely outcome.<ref name="WilkinsonTheFAIR16" /><ref name="OlsenEmbracing23" /><ref name="HuertaFAIRForAI23" />


2. A LIMS needs to satisfy good manufacturing practice (GMP) and meet the reporting and audit needs of the U.S. [[Food and Drug Administration]] and research scientists in many different industries. A LIS, however, must satisfy the reporting and auditing needs of [[hospital]] accreditation agencies, [[HIPAA]], and other clinical medical practitioners.<ref name="lislims1" />
3. A LIMS is most competitive in group-centric settings (dealing with "batches" and "samples") that often deal with mostly anonymous research-specific laboratory data, whereas a LIS is usually most competitive in patient-centric settings (dealing with "subjects" and "specimens") and clinical labs.<ref name="analytica" /><ref name="lislims2">{{cite web |url=http://labsoftnews.typepad.com/lab_soft_news/2008/11/lis-vs-lims.html |title=LIS vs. LIMS: Some New Insights |author=Friedman, B. |work=Lab Soft News |date=19 November 2008 |accessdate=13 March 2024}}</ref><ref name="starlims">{{cite web |url=http://blog.starlims.com/2009/07/01/swimming-in-the-clinical-pool-why-lims-are-supplanting-old-school-clinical-lis-applications/ |archiveurl=https://web.archive.org/web/20110313145726/http://blog.starlims.com/2009/07/01/swimming-in-the-clinical-pool-why-lims-are-supplanting-old-school-clinical-lis-applications/ |title=Swimming in the Clinical Pool: Why LIMS are supplanting old-school clinical LIS applications |author=Hice, R. |publisher=STARLIMS Corporation |date=01 July 2009 |archivedate=13 March 2011 |accessdate=13 March 2024}}</ref>
However, these distinctions began to fade somewhat in the early 2010s as some LIMS vendors began to adopt the case-centric information management normally reserved for a LIS, blurring the lines between the two components further.<ref name="starlims" /> [[Thermo Scientific]]'s Clinical LIMS was an example of this merger of LIMS with LIS, with Dave Champagne, informatics vice president and general manager, stating: "Routine molecular diagnostics requires a convergence of the up-to-now separate systems that have managed work in the lab (the LIMS) and the clinic (the LIS). The industry is asking for, and the science is requiring, a single lab-centric solution that delivers patient-centric results."<ref name="ConvergeLimsLis">{{cite web |url=https://clpmag.com/lab-essentials/information-technology/convergence-of-lims-and-lis/ |title=Convergence of LIMS and LIS |author=Tufel, G. |work=Clinical Lab Products |publisher=MEDQOR |date=01 February 2012 |accessdate=13 March 2024}}</ref> [[Abbott Informatics Corporation]]'s STARLIMS product was another example of this LIMS/LIS merger.<ref name="StarlimsLimsLis" /> With the distinction between the two entities becoming less clear, discussions within the laboratory informatics community began to includes the question of whether or not the two entities should be considered the same.<ref name="LinkedInDifLisLims">{{cite web |url=https://www.linkedin.com/feed/update/urn:li:groupPost:2069898-98494737/ |title=What is the difference between a LIS and a LIMS? |author=Jones, J. |publisher=LinkedIn |date=March 2012 |accessdate=13 March 2024}}</ref><ref name="LinkedInLisLimsSame">{{cite web |url=http://www.linkedin.com/groups/Are-LIMS-LIS-same-thing-2069898.S.147132083 |title=Are LIMS and LIS the same thing? |author=Jones, John |publisher=LinkedIn |date=September 2012 |accessdate=07 November 2012}}{{Dead link}}</ref> {{As of|2024}}, vendors continue to recognize the historical differences between the two products while also continuing to acknowledge that some developed LIMS are taking on more of the clinical aspects usually reserved for a LIS.<ref name="AgilabFAQ">{{cite web |url=http://agilab.com/faq/ |archiveurl=https://web.archive.org/web/20190325075813/http://agilab.com/faq/ |title=FAQ: What is the difference between a LIMS and a medical laboratory quality system? |publisher=AgiLab SAS |archivedate=25 March 2019 |accessdate=13 March 2024}}</ref><ref name="ReisenwitzWhatIs17">{{cite web |url=https://www.capterra.com/resources/what-is-a-laboratory-information-management-system/ |title=What Is a Laboratory Information Management System? |author=Reisenwitz, C. |work=Capterra Medical Software Blog |publisher=Capterra, Inc |date=11 May 2017 |accessdate=13 March 2024}}</ref><ref name="CloudLISDifference16">{{cite web |url=https://cloudlims.com/lims-vs-lis/ |title=LIS vs LIMS: Uncover the Difference & Choose the Right Informatics Solution |publisher=CloudLIMS.com, LLC |date=12 October 2023 |accessdate=13 March 2024}}</ref>
==Standards affecting LIMS==
A LIMS' development and use is affected by standards such as:
*[[21 CFR Part 11|Title 21 CFR Part 11]] from the [[Food and Drug Administration]] (United States)
*[[ISO 17025]]
*[[ISO 15189]]
*[[Good laboratory practice]]
==LIMS vendors==
See the [[LIMS vendor]] page for a list of LIMS vendors past and present.
==See also==
*[[Laboratory informatics]]
*[[LIMS feature|Common LIMS features]]
==Further reading==
* {{cite journal |title=A brief history of LIMS |journal=Laboratory Automation and Information Management|author=Gibbon, G.A. |volume=32 |issue=1 |pages=1–5 |year=1996 |doi=10.1016/1381-141X(95)00024-K}}
* {{cite web |url=https://www.it.uu.se/edu/course/homepage/lims/vt12/ComprehensiveLaboratoryInformatics.pdf |archiveurl=https://web.archive.org/web/20170825181932/https://www.it.uu.se/edu/course/homepage/lims/vt12/ComprehensiveLaboratoryInformatics.pdf |format=PDF |title=Comprehensive Laboratory Informatics: A Multilayer Approach |author=Wood, S. |work=American Laboratory |page=1 |date=September 2007 |archivedate=25 August 2017}}
==References==
==References==
{{Reflist|colwidth=30em}}
{{Reflist|colwidth=30em}}
<!---Place all category tags here-->
<!---Place all category tags here-->

Latest revision as of 22:10, 9 May 2024

This is sublevel12 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see my discussion page instead.

Sandbox begins below

FAIRResourcesGraphic AustralianResearchDataCommons 2018.png

Title: What are the potential implications of the FAIR data principles to laboratory informatics applications?

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: May 2024

Introduction

This brief topical article will examine

The "FAIR-ification" of research objects and software

First discussed during a 2014 FORCE-11 workshop dedicated to "overcoming data discovery and reuse obstacles," the FAIR data principles were published by Wilkinson et al. in 2016 as a stakeholder collaboration driven to see research "objects" (i.e., research data and information of all shapes and formats) become more universally findable, accessible, interoperable, and reusable (FAIR) by both machines and people.[1] The authors released the FAIR principles while recognizing that "one of the grand challenges of data-intensive science ... is to improve knowledge discovery through assisting both humans and their computational agents in the discovery of, access to, and integration and analysis of task-appropriate scientific data and other scholarly digital objects."[1]

Since 2016, other research stakeholders have taken to publishing their thoughts about how the FAIR principles apply to their fields of study and practice[2], including in ways beyond what perhaps was originally imagined by Wilkinson et al.. For example, multiple authors have examined whether or not the software used in scientific endeavors itself can be considered a research object worth being developed and managed in tandem with the FAIR data principles.[3][4][5][6][7] Researchers quickly recognized that any planning around updating processes and systems to make research objects more FAIR would have to be tailored to specific research contexts, recognize that digital research objects go beyond data and information, and recognize "the specific nature of software" and not consider it "just data."[4] The end result has been applying the core concepts of FAIR but differently from data, with the added context of research software being more than just data, requiring more nuance and a different type of planning from applying FAIR to digital data and information.

A 2019 survey by Europe's FAIRsFAIR found that researchers seeking and re-using relevant research software on the internet faced multiple challenges, including understanding and/or maintaining the necessary software environment and its dependencies, finding sufficient documentation, struggling with accessibility and licensing issues, having the time and skills to install and/or use the software, finding quality control of the source code lacking, and having an insufficient (or non-existent) software sustainability and management plan.[4] These challenges highlight the importance of software to researchers and other stakeholders, and the roll FAIR has in better ensuring such software is findable, interoperable, and reusable, which in turn better ensures researchers' software-driven research is repeatable (by the same research team, with the same experimental setup), reproducible (by a different research team, with the same experimental setup), and replicable (by a different research team, with a different experimental setup).[4]

At this point, the topic of what "research software" represents must be addressed further, and, unsurprisingly, it's not straightforward. Ask 20 researchers what "research software" is, and you may get 20 different opinions. Some definitions can be more objectively viewed as too narrow, while others may be viewed as too broad, with some level of controversy inherent in any mutual discussion.[8][9][10] In 2021, as part of the FAIRsFAIR initiative, Gruenpeter et al. made a good-faith effort to define "research software" with the feedback of multiple stakeholders. Their efforts resulted in this definition[8]:

Research software includes source code files, algorithms, scripts, computational workflows, and executables that were created during the research process, or for a research purpose. Software components (e.g., operating systems, libraries, dependencies, packages, scripts, etc.) that are used for research but were not created during, or with a clear research intent, should be considered "software [used] in research" and not research software. This differentiation may vary between disciplines. The minimal requirement for achieving computational reproducibility is that all the computational components (i.e., research software, software used in research, documentation, and hardware) used during the research are identified, described, and made accessible to the extent that is possible.

Note that while the definition primarily recognizes software created during the research process, software created (whether by the research group, other open-source software developers outside the organization, or even commercial software developers) "for a research purpose" outside the actual research process is also recognized as research software. This notably can lead to disagreement about whether a proprietary, commercial spreadsheet or laboratory information management system (LIMS) offering that conducts analyses and visualizations of research data can genuinely be called research software, or simply classified as software used in research. van Nieuwpoort and Katz further elaborated on this concept, at least indirectly, by formally defining the roles of research software in 2023. Their definition of the various roles of research software—without using terms such as "open-source," "commercial," or "proprietary"—essentially further defined what research software is[10]:

  • Research software is a component of our instruments.
  • Research software is the instrument.
  • Research software analyzes research data.
  • Research software presents research results.
  • Research software assembles or integrates existing components into a working whole.
  • Research software is infrastructure or an underlying tool.
  • Research software facilitates distinctively research-oriented collaboration.

When considering these definitions[8][10] of research software and their adoption by other entities[11], it would appear that at least in part some laboratory informatics software—whether open-source or commercially proprietary—fills these roles in academic, military, and industry research laboratories of many types. In particular, electronic laboratory notebooks (ELNs) like open-source Jupyter Notebook or proprietary ELNs from commercial software developers fill the role of analyzing and visualizing research data, including developing molecular models for new promising research routes.[10] Even more advanced LIMS solutions that go beyond simply collating, auditing, securing, and reporting analytical results could conceivably fall under the umbrella of research software, particularly if many of the analytical, integration, and collaboration tools required in modern research facilities are included in the LIMS.

Ultimately, assuming that some laboratory informatics software can be considered research software and not just "software used in research," it's tough not to arrive at some deeper implications of research organizations' increasing need for FAIR data objects and software, particularly for laboratory informatics software and the developers of it.

Implications of the FAIR concept to laboratory informatics software

The global FAIR initiative affects, and even benefits, commercial laboratory informatics research software developers as much as it does academic and institutional ones

To be clear, there is undoubtedly a difference in the software development approach of "homegrown" research software by academics and institutions, and the more streamlined and experienced approach of commercial software development houses as applied to research software. Moynihan of Invenia Technical Computing described the difference in software development approaches thusly in 2020, while discussing the concept of "research software engineering"[12]:

Since the environment and incentives around building academic research software are very different to those of industry, the workflows around the former are, in general, not guided by the same engineering practices that are valued in the latter. That is to say: there is a difference between what is important in writing software for research, and for a user-focused software product. Academic research software prioritizes scientific correctness and flexibility to experiment above all else in pursuit of the researchers’ end product: published papers. Industry software, on the other hand, prioritizes maintainability, robustness, and testing, as the software (generally speaking) is the product. However, the two tracks share many common goals as well, such as catering to “users” [and] emphasizing performance and reproducibility, but most importantly both ventures are collaborative. Arguably then, both sets of principles are needed to write and maintain high-quality research software.

This brings us to our first point: the application of small-scale, FAIR-driven academic research software engineering practices and elements to the larger development of more commercial laboratory informatics software, and vice versa with the application of commercial-scale development practices to small FAIR-focused academic and institutional research software engineering efforts, has the potential to help better support all research laboratories using both independently-developed and commercial research software.

The concept of the research software engineer (RSE) began to take full form in 2012, and since then universities and institutions of many types have formally developed their own RSE groups and academic programs.[13][14][15] RSEs range from pure software developers with little knowledge of a given research discipline, to scientific researchers just beginning to learn how to develop software for their research project(s). While in the past, broadly speaking, researchers often cobbled together research software with less a focus on quality and reproducibility and more on getting their research published, today's push for FAIR data and software by academic journals, institutions, and other researchers seeking to collaborate has placed a much greater focus on the concept of "better software, better research."[13][16] Elaborating on that concept, Cohen et al. add that "ultimately, good research software can make the difference between valid, sustainable, reproducible research outputs and short-lived, potentially unreliable or erroneous outputs."[16]

The concept of software quality management (SQM) has traditionally not been lost on professional, commercial software development businesses. Good SQM practices have been less prevalent in homegrown research software development; however, the expanded adoption of FAIR data and FAIR software approaches has shifted the focus on to the repeatability, reproducibility, and interoperability of research results and data produced by a more sustainable research software. The adoption of FAIR by academic and institutional research labs not only brings commercial SQM and other software development approaches into their workflow, but also gives commercial laboratory informatics software developers an opportunity to embrace many aspects of the FAIR approach to laboratory research practices, including lessons learned and development practices from the growing number of RSEs. This doesn't mean commercial developers are going to suddenly take an open-source approach to their code, and it doesn't mean academic and institutional research labs are going to give up the benefits of the open-source paradigm as applied to research software.[17] However, as Moynihan noted, both research software development paradigms stand to gain from the shift to more FAIR data and software.[12] Additionally, if commercial laboratory informatics vendors want to continue to competitively market relevant and sustainable research software to research labs, they frankly have little choice but to commit extra resources to learning about the application of FAIR principles to their offerings tailored to those labs.

The focus on data types and metadata within the scope of FAIR is shifting how laboratory informatics software developers and RSEs make their research software and choose their database approaches

Close to the core of any deep discussion of the FAIR data principles are the concepts of data models, data types, metadata, and persistent unique identifiers (PIDs). Making research objects more findable, accessible, interoperable, and reusable is no easy task when data types and approaches to metadata assignment (if there even is such an approach) are widely differing and inconsistent. Metadata is a means for better storing and characterizing research objects for the purposes of ensuring provenance and reproducibility of those research objects.[18][19] This means as early as possible implementing a software-based approach that is FAIR-driven, capturing FAIR metadata using flexible domain-driven ontologies (i.e., controlled vocabularies) at the source and cleaning up old research objects that aren't FAIR-ready while also limiting hindrances to research processes as much as possible.[19] And that approach must value the importance of metadata and PIDs. As Weigel et al. note in a discussion on making laboratory data and workflows more machine-findable: "Metadata capture must be highly automated and reliable, both in terms of technical reliability and ensured metadata quality. This requires an approach that may be very different from established procedures."[20] Enter non-relational RDF knowledge graph databases.

This brings us to our second point: given the importance of metadata and PIDs to FAIRifying research objects (and even research software), established, more traditional research software development methods using common relational databases may not be enough, even for commercial laboratory informatics software developers. Non-relational Resource Description Framework (RDF) knowledge graph databases used in FAIR-driven, well-designed laboratory informatics software help make research objects more FAIR for all research labs.

Research objects can take many forms (i.e., data types), making the storage and management of those objects challenging, particularly in research settings with great diversity of data, as with materials research. Some have approached this challenge by combining different database and systems technologies that are best suited for each data type.[21] However, while query performance and storage footprint improves with this approach, data across the different storage mechanisms typically remains unlinked and non-compliant with FAIR principles. Here, either a full RDF knowledge graph database or similar integration layer is required to better make the research objects more interoperable and reusable, whether it's materials records or specimen data.[21][22]

It is beyond the scope of this Q&A article to discuss RDF knowledge graph databases at length. (For a deeper dive on this topic, see Rocca-Serra et al. and the FAIR Cookbook.[23]) However, know that the primary strength of these databases to FAIRification of research objects is their ability to provide semantic transparency (i.e., provide a framework for better understanding and reusing the greater research object through basic examination of the relationships of its associated metadata and their constituents), making these objects more easily accessible, interoperable, and machine-readable.[21] The resulting knowledge graphs, with their "subject-property-object" syntax and PIDs or uniform resource identifiers (URIs) helping to link data, metadata, ontology classes, and more, can be interpreted, searched, and linked by machines, and made human-readable, resulting in better research through derivation of new knowledge from the existing research objects. The end result is a representation of heterogeneous data and metadata that complies with the FAIR guiding principles.[21][22][23][24][25][26] This concept can even be extended to post factum visualizations of the knowledge graph data[25], as well as the FAIR management of computational laboratory workflows.[27]

While rare, some commercial laboratory informatics vendors like Semaphore Solutions have already recognized the potential of RDF knowledge graph databases to FAIR-driven laboratory research, having implemented such structures into their offerings.[24] (The use of knowledge graphs has already been demonstrated in academic research software, such as with the ELN tools developed by RSEs at the University of Rostock and University of Amsterdam.[28]) As noted in the prior point, it is potentially advantageous to not only laboratory informatics vendors to provide but also research labs to use relevant and sustainable research software that has the FAIR principles embedded in the software's design. Turning to knowledge graph databases is another example of keeping such software relevant and FAIR to research labs.

Applying FAIR-driven metadata schemes to laboratory informatics software development gives data a FAIRer chance at being ready for machine learning and artificial intelligence applications

The third and final point for this Q&A article highlights another positive consequence of engineering laboratory informatics software with FAIR in mind: FAIRified research objects are much closer to being usable for the trending inclusion of machine learning (ML) and artificial intelligence (AI) tools in laboratory informatics platforms and other companion research software. By developing laboratory informatics software with a focus on FAIR-driven metadata and database schemes, not only are research objects more FAIR but also "cleaner" and more machine-ready for advanced analytical uses as with ML and AI.

To be sure, the FAIRness of any structured dataset alone is not enough to make it ready for ML and AI applications. Factors such as classification, completeness, context, correctness, duplicity, integrity, mislabeling, outliers, relevancy, sample size, and timeliness of the research object and its contents are also important to consider.[29][30] When those factors aren't appropriately addressed as part of a FAIRification effort towards AI readiness (as well as part of the development of research software of all types), research data and metadata have a higher likelihood of revealing themselves to be inconsistent. As such, searches and analytics using that data and metadata become muddled, and the ultimate ML or AI output will also be muddled (i.e., "garbage in, garbage out"). Whether retroactively updating existing research objects to a more FAIRified state or ensuring research objects (e.g., those originating in an ELN or LIMS) are more FAIR and AI-ready from the start, research software updating or generating those research objects has to address ontologies, data models, data types, identifiers, and more in a thorough yet flexible way.[31]

Noting that Wilkinson et al. originally highlighted the importance of machine-readability of FAIR data, Huerta et al. add that that core principle of FAIRness "is synergistic with the rapid adoption and increased use of AI in research."[32] They go on to discuss the positive interactions of FAIR research objects with FAIR-driven, AI-based research. Among the benefits include[32]:

  • greater findability of FAIR research objects for further AI-driven scientific discovery;
  • greater reproducibility of FAIR research objects and any AI models published with them;
  • improved generalization of AI-driven medical research models when exposed to diverse and FAIR research objects;
  • improved reporting of AI-driven research results using FAIRified research objects, lending further credibility to those results;
  • more uniform comparison of AI models using well-defined hyperstructure and information training conditions from FAIRified research objects;
  • more developed and interoperable "data e-infrastructure," which can further drive a more effective "AI services layer";
  • reduced bias in AI-driven processes through the use of FAIR research objects and AI models; and
  • improved surety of scientific correctness where reproducibility in AI-driven research can't be guaranteed.

In the end, developers of research software (whether discipline-specific research software or broader laboratory informatics solutions) would be advised to keep in mind the growing trends of FAIR research, FAIR software, and ML- and AI-driven research, especially in the life sciences, but also a variety of other fields.[32]

Restricted clinical data and its FAIRification for greater research innovation

Broader discussion in the research community continues to occur in regards to how best to ethically make restricted or privacy-protected clinical data and information FAIR for greater innovation and, by extension, improved patient outcomes, particularly in the wake of the COVID-19 pandemic.[33][34][35] (Note that while there are other types of restricted and privacy-protected data, this section will focus largely on clinical data and research objects as the most obvious type.)

These efforts have usually revolved around pulling reusable clinical patient or research data from hospital information systems (HIS), electronic medical records (EMRs), clinical trial management systems (CTMSs), and research databases (often relational in nature) that either contain de-identified data or can de-identify aspects of data and information before access and extraction. Sometimes that clinical data or research object may have already in part been FAIRified, but often it may not be. In all cases, the concepts of privacy, security, and anonymization come up as part of any desire to gain access to that clinical material. However, any FAIRified clinical data isn't necessarily readily open for access. As Snoeijer et al. note: "The authors of the FAIR principles, however, clearly indicate that 'accessible' does not mean open. It means that clarity and transparency is required around the conditions governing access and reuse."[36]

This is being mentioned in the context of laboratory informatics applications for a couple of reasons. First, a well-designed commercial LIMS that supports clinical research laboratory workflows is already going to address privacy and security aspects, as part of the developer recognizing the need for those labs to adhere to regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and comply with standards such as ISO 15189. However, such a system may not have been developed with FAIR data principles in mind, and any built-in metadata and ontology schemes may be insufficient for full FAIRification of laboratory-based clinical trial research objects. As Queralt-Rosinach et al. note, however, "interestingly, ontologies may also be used to describe data access restrictions to complement FAIR metadata with information that supports data safety and patient privacy."[34] Essentially, the authors are suggesting that while a HIS or LIS may have built-in access management tools, setting up ontologies and metadata mechanisms that link privacy aspects of a research object (e.g., "has consent form for," "is de-identified," etc.) to the object's metadata allows for even more flexible, FAIR-driven approaches to privacy and security. Research software developers creating such information management tools for the regulated clinical research space may want to apply FAIR concepts such as this to how access control and privacy restrictions are managed. This will inevitably mean any research objects exported with machine-readable privacy-concerning metadata will be more reusable in a way that still "supports data safety and patient privacy."[34]

Second, a well-designed research software solution working with clinical data will provide not only support for open, community-supported data models and vocabularies for clinical data, but also standardized community-driven ontologies that are specifically developed for access control and privacy. Queralt-Rosinach et al. continue[34]:

Also, very important for accessibility and data privacy is that the digital objects per se can accommodate the criteria and protocols necessary to comply with regulatory and governance frameworks. Ontologies can aid in opening and protecting patient data by exposing logical definitions of data use conditions. Indeed, there are ontologies to define access and reuse conditions for patient data such as the Informed Consent Ontology (ICO), the Global Alliance for Genomics and Health Data Use Ontology (DUO) standard, and the Open Digital Rights Language (ODRL) vocabulary recommended by W3C.

Also of note here is the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) and its OHDSI standardized vocabularies. In all these cases, a developer-driven approach to research software that incorporates community-driven standards that support FAIR principles is welcome. However, as Maxwell et al. noted in their Lancet review article in late 2023, "few platforms or registries applied community-developed standards for participant-level data, further restricting the interoperability of ... data-sharing initiatives [like FAIR]."[33] As the FAIR principles continue to gain ground in clinical research and diagnostics settings, software developers will need to be more attuned to translating old ways of development to ones that incorporate FAIR data and software principles. Demand for FAIR data will only continue to grow, and any efforts to improve interoperability and reusability while honoring (and enhancing) privacy and security aspects of restricted data will be appreciated by clinical researchers. However, just as FAIR is not an overall goal for researchers, software built with FAIR principles in mind is not the end point of research organizations managing restricted and privacy-protected research objects. Ultimately, those organizations will have make other considerations about restricted data in the scope of FAIR, including addressing data management plans, data use agreements, disclosure review practices, and training as it applies to their research software and generated research objects.[37]

Conclusion

Laboratory informatics developers will also need to remember that FAIRification of research in itself is not a goal for research laboratories; it is a continual process that recognizes improved scientific research and greater innovation as a more likely outcome.[1][31][32]

References

  1. ↑ 1.0 1.1 1.2 Wilkinson, Mark D.; Dumontier, Michel; Aalbersberg, IJsbrand Jan; Appleton, Gabrielle; Axton, Myles; Baak, Arie; Blomberg, Niklas; Boiten, Jan-Willem et al. (15 March 2016). "The FAIR Guiding Principles for scientific data management and stewardship" (in en). Scientific Data 3 (1): 160018. doi:10.1038/sdata.2016.18. ISSN 2052-4463. PMC PMC4792175. PMID 26978244. https://www.nature.com/articles/sdata201618. 
  2. ↑ "fair data principles". PubMed Search. National Institutes of Health, National Library of Medicine. https://pubmed.ncbi.nlm.nih.gov/?term=fair+data+principles. Retrieved 30 April 2024. 
  3. ↑ Hasselbring, Wilhelm; Carr, Leslie; Hettrick, Simon; Packer, Heather; Tiropanis, Thanassis (25 February 2020). "From FAIR research data toward FAIR and open research software" (in en). it - Information Technology 62 (1): 39–47. doi:10.1515/itit-2019-0040. ISSN 2196-7032. https://www.degruyter.com/document/doi/10.1515/itit-2019-0040/html. 
  4. ↑ 4.0 4.1 4.2 4.3 Gruenpeter, M. (23 November 2020). "FAIR + Software: Decoding the principles" (PDF). FAIRsFAIR “Fostering FAIR Data Practices In Europe”. https://www.fairsfair.eu/sites/default/files/FAIR%20%2B%20software.pdf. Retrieved 30 April 2024. 
  5. ↑ Barker, Michelle; Chue Hong, Neil P.; Katz, Daniel S.; Lamprecht, Anna-Lena; Martinez-Ortiz, Carlos; Psomopoulos, Fotis; Harrow, Jennifer; Castro, Leyla Jael et al. (14 October 2022). "Introducing the FAIR Principles for research software" (in en). Scientific Data 9 (1): 622. doi:10.1038/s41597-022-01710-x. ISSN 2052-4463. PMC PMC9562067. PMID 36241754. https://www.nature.com/articles/s41597-022-01710-x. 
  6. ↑ Patel, Bhavesh; Soundarajan, Sanjay; Ménager, Hervé; Hu, Zicheng (23 August 2023). "Making Biomedical Research Software FAIR: Actionable Step-by-step Guidelines with a User-support Tool" (in en). Scientific Data 10 (1): 557. doi:10.1038/s41597-023-02463-x. ISSN 2052-4463. PMC PMC10447492. PMID 37612312. https://www.nature.com/articles/s41597-023-02463-x. 
  7. ↑ Du, Xinsong; Dastmalchi, Farhad; Ye, Hao; Garrett, Timothy J.; Diller, Matthew A.; Liu, Mei; Hogan, William R.; Brochhausen, Mathias et al. (6 February 2023). "Evaluating LC-HRMS metabolomics data processing software using FAIR principles for research software" (in en). Metabolomics 19 (2): 11. doi:10.1007/s11306-023-01974-3. ISSN 1573-3890. https://link.springer.com/10.1007/s11306-023-01974-3. 
  8. ↑ 8.0 8.1 8.2 Gruenpeter, Morane; Katz, Daniel S.; Lamprecht, Anna-Lena; Honeyman, Tom; Garijo, Daniel; Struck, Alexander; Niehues, Anna; Martinez, Paula Andrea et al. (13 September 2021). "Defining Research Software: a controversial discussion". Zenodo. doi:10.5281/zenodo.5504016. https://zenodo.org/record/5504016. 
  9. ↑ "What is Research Software?". JuRSE, the Community of Practice for Research Software Engineering. Forschungszentrum Jülich. 13 February 2024. https://www.fz-juelich.de/en/rse/about-rse/what-is-research-software. Retrieved 30 April 2024. 
  10. ↑ 10.0 10.1 10.2 10.3 van Nieuwpoort, Rob; Katz, Daniel S. (14 March 2023) (in en). Defining the roles of research software. doi:10.54900/9akm9y5-5ject5y. https://upstream.force11.org/defining-the-roles-of-research-software. 
  11. ↑ "Open source software and code". F1000 Research Ltd. 2024. https://www.f1000.com/resources-for-researchers/open-research/open-source-software-code/. Retrieved 30 April 2024. 
  12. ↑ 12.0 12.1 Moynihan, G. (7 July 2020). "The Hitchhiker’s Guide to Research Software Engineering: From PhD to RSE". Invenia Blog. Invenia Technical Computing Corporation. https://invenia.github.io/blog/2020/07/07/software-engineering/. 
  13. ↑ 13.0 13.1 Woolston, Chris (31 May 2022). "Why science needs more research software engineers" (in en). Nature: d41586–022–01516-2. doi:10.1038/d41586-022-01516-2. ISSN 0028-0836. https://www.nature.com/articles/d41586-022-01516-2. 
  14. ↑ "RSE@KIT". Karlsruhe Institute of Technology. 20 February 2024. https://www.rse-community.kit.edu/index.php. Retrieved 01 May 2024. 
  15. ↑ "Purdue Center for Research Software Engineering". Purdue University. 2024. https://www.rcac.purdue.edu/rse. Retrieved 01 May 2024. 
  16. ↑ 16.0 16.1 Cohen, Jeremy; Katz, Daniel S.; Barker, Michelle; Chue Hong, Neil; Haines, Robert; Jay, Caroline (1 January 2021). "The Four Pillars of Research Software Engineering". IEEE Software 38 (1): 97–105. doi:10.1109/MS.2020.2973362. ISSN 0740-7459. https://ieeexplore.ieee.org/document/8994167/. 
  17. ↑ Hasselbring, Wilhelm; Carr, Leslie; Hettrick, Simon; Packer, Heather; Tiropanis, Thanassis (25 February 2020). "From FAIR research data toward FAIR and open research software" (in en). it - Information Technology 62 (1): 39–47. doi:10.1515/itit-2019-0040. ISSN 2196-7032. https://www.degruyter.com/document/doi/10.1515/itit-2019-0040/html. 
  18. ↑ Ghiringhelli, Luca M.; Baldauf, Carsten; Bereau, Tristan; Brockhauser, Sandor; Carbogno, Christian; Chamanara, Javad; Cozzini, Stefano; Curtarolo, Stefano et al. (14 September 2023). "Shared metadata for data-centric materials science" (in en). Scientific Data 10 (1): 626. doi:10.1038/s41597-023-02501-8. ISSN 2052-4463. PMC PMC10502089. PMID 37709811. https://www.nature.com/articles/s41597-023-02501-8. 
  19. ↑ 19.0 19.1 Fitschen, Timm; tom Wörden, Henrik; Schlemmer, Alexander; Spreckelsen, Florian; Hornung, Daniel (12 October 2022). "Agile Research Data Management with FDOs using LinkAhead". Research Ideas and Outcomes 8: e96075. doi:10.3897/rio.8.e96075. ISSN 2367-7163. https://riojournal.com/article/96075/. 
  20. ↑ Weigel, Tobias; Schwardmann, Ulrich; Klump, Jens; Bendoukha, Sofiane; Quick, Robert (1 January 2020). "Making Data and Workflows Findable for Machines" (in en). Data Intelligence 2 (1-2): 40–46. doi:10.1162/dint_a_00026. ISSN 2641-435X. https://direct.mit.edu/dint/article/2/1-2/40-46/9994. 
  21. ↑ 21.0 21.1 21.2 21.3 Aggour, Kareem S.; Kumar, Vijay S.; Gupta, Vipul K.; Gabaldon, Alfredo; Cuddihy, Paul; Mulwad, Varish (9 April 2024). "Semantics-Enabled Data Federation: Bringing Materials Scientists Closer to FAIR Data" (in en). Integrating Materials and Manufacturing Innovation. doi:10.1007/s40192-024-00348-4. ISSN 2193-9764. https://link.springer.com/10.1007/s40192-024-00348-4. 
  22. ↑ 22.0 22.1 Grobe, Peter; Baum, Roman; Bhatty, Philipp; Köhler, Christian; Meid, Sandra; Quast, Björn; Vogt, Lars (26 June 2019). "From Data to Knowledge: A semantic knowledge graph application for curating specimen data" (in en). Biodiversity Information Science and Standards 3: e37412. doi:10.3897/biss.3.37412. ISSN 2535-0897. https://biss.pensoft.net/article/37412/. 
  23. ↑ 23.0 23.1 Rocca-Serra, Philippe; Sansone, Susanna-Assunta; Gu, Wei; Welter, Danielle; Abbassi Daloii, Tooba; Portell-Silva, Laura (30 June 2022). "FAIR and Knowledge graphs". D2.1 FAIR Cookbook. doi:10.5281/ZENODO.6783564. https://zenodo.org/record/6783564. 
  24. ↑ 24.0 24.1 Tomlinson, E. (28 July 2023). "RDF Knowledge Graph Databases: A Better Choice for Life Science Lab Software" (PDF). Semaphore Solutions, Inc. https://21624527.fs1.hubspotusercontent-na1.net/hubfs/21624527/Resources/RDF%20Knowledge%20Graph%20Databases%20White%20Paper.pdf. Retrieved 01 May 2024. 
  25. ↑ 25.0 25.1 Deagen, Michael E.; McCusker, Jamie P.; Fateye, Tolulomo; Stouffer, Samuel; Brinson, L. Cate; McGuinness, Deborah L.; Schadler, Linda S. (27 May 2022). "FAIR and Interactive Data Graphics from a Scientific Knowledge Graph" (in en). Scientific Data 9 (1): 239. doi:10.1038/s41597-022-01352-z. ISSN 2052-4463. PMC PMC9142568. PMID 35624233. https://www.nature.com/articles/s41597-022-01352-z. 
  26. ↑ Brandizi, Marco; Singh, Ajit; Rawlings, Christopher; Hassani-Pak, Keywan (25 September 2018). "Towards FAIRer Biological Knowledge Networks Using a Hybrid Linked Data and Graph Database Approach" (in en). Journal of Integrative Bioinformatics 15 (3): 20180023. doi:10.1515/jib-2018-0023. ISSN 1613-4516. PMC PMC6340125. PMID 30085931. https://www.degruyter.com/document/doi/10.1515/jib-2018-0023/html. 
  27. ↑ de Visser, Casper; Johansson, Lennart F.; Kulkarni, Purva; Mei, Hailiang; Neerincx, Pieter; Joeri van der Velde, K.; Horvatovich, Péter; van Gool, Alain J. et al. (28 September 2023). Palagi, Patricia M.. ed. "Ten quick tips for building FAIR workflows" (in en). PLOS Computational Biology 19 (9): e1011369. doi:10.1371/journal.pcbi.1011369. ISSN 1553-7358. PMC PMC10538699. PMID 37768885. https://dx.plos.org/10.1371/journal.pcbi.1011369. 
  28. ↑ Schröder, Max; Staehlke, Susanne; Groth, Paul; Nebe, J. Barbara; Spors, Sascha; Krüger, Frank (1 December 2022). "Structure-based knowledge acquisition from electronic lab notebooks for research data provenance documentation" (in en). Journal of Biomedical Semantics 13 (1): 4. doi:10.1186/s13326-021-00257-x. ISSN 2041-1480. PMC PMC8802522. PMID 35101121. https://jbiomedsem.biomedcentral.com/articles/10.1186/s13326-021-00257-x. 
  29. ↑ Hiniduma, Kaveen; Byna, Suren; Bez, Jean Luca (2024). "Data Readiness for AI: A 360-Degree Survey". arXiv. doi:10.48550/ARXIV.2404.05779. https://arxiv.org/abs/2404.05779. 
  30. ↑ Fletcher, Lydia (16 April 2024). FAIR Re-use: Implications for AI-Readiness. The University Of Texas At Austin, The University Of Texas At Austin. doi:10.26153/TSW/51475. https://repositories.lib.utexas.edu/handle/2152/124873. 
  31. ↑ 31.0 31.1 Olsen, C. (1 September 2023). "Embracing FAIR Data on the Path to AI-Readiness". Pharma's Almanac. https://www.pharmasalmanac.com/articles/embracing-fair-data-on-the-path-to-ai-readiness. Retrieved 03 May 2024. 
  32. ↑ 32.0 32.1 32.2 32.3 Huerta, E. A.; Blaiszik, Ben; Brinson, L. Catherine; Bouchard, Kristofer E.; Diaz, Daniel; Doglioni, Caterina; Duarte, Javier M.; Emani, Murali et al. (26 July 2023). "FAIR for AI: An interdisciplinary and international community building perspective" (in en). Scientific Data 10 (1): 487. doi:10.1038/s41597-023-02298-6. ISSN 2052-4463. PMC PMC10372139. PMID 37495591. https://www.nature.com/articles/s41597-023-02298-6. 
  33. ↑ 33.0 33.1 Maxwell, Lauren; Shreedhar, Priya; Dauga, Delphine; McQuilton, Peter; Terry, Robert F; Denisiuk, Alisa; Molnar-Gabor, Fruzsina; Saxena, Abha et al. (1 October 2023). "FAIR, ethical, and coordinated data sharing for COVID-19 response: a scoping review and cross-sectional survey of COVID-19 data sharing platforms and registries" (in en). The Lancet Digital Health 5 (10): e712–e736. doi:10.1016/S2589-7500(23)00129-2. PMC PMC10552001. PMID 37775189. https://linkinghub.elsevier.com/retrieve/pii/S2589750023001292. 
  34. ↑ 34.0 34.1 34.2 34.3 Queralt-Rosinach, Núria; Kaliyaperumal, Rajaram; Bernabé, César H.; Long, Qinqin; Joosten, Simone A.; van der Wijk, Henk Jan; Flikkenschild, Erik L.A.; Burger, Kees et al. (1 December 2022). "Applying the FAIR principles to data in a hospital: challenges and opportunities in a pandemic" (in en). Journal of Biomedical Semantics 13 (1): 12. doi:10.1186/s13326-022-00263-7. ISSN 2041-1480. PMC PMC9036506. PMID 35468846. https://jbiomedsem.biomedcentral.com/articles/10.1186/s13326-022-00263-7. 
  35. ↑ Martínez-García, Alicia; Alvarez-Romero, Celia; Román-Villarán, Esther; Bernabeu-Wittel, Máximo; Luis Parra-Calderón, Carlos (1 May 2023). "FAIR principles to improve the impact on health research management outcomes" (in en). Heliyon 9 (5): e15733. doi:10.1016/j.heliyon.2023.e15733. PMC PMC10189186. PMID 37205991. https://linkinghub.elsevier.com/retrieve/pii/S2405844023029407. 
  36. ↑ Snoeijer, B.; Pasapula, V.; Covucci, A. et al. (2019). "Paper SA04 - Processing big data from multiple sources" (PDF). Proceedings of PHUSE Connect EU 2019. PHUSE Limited. https://phuse.s3.eu-central-1.amazonaws.com/Archive/2019/Connect/EU/Amsterdam/PAP_SA04.pdf. Retrieved 03 May 2024. 
  37. ↑ Jang, Joy Bohyun; Pienta, Amy; Levenstein, Margaret; Saul, Joe (6 December 2023). "Restricted data management: the current practice and the future". Journal of Privacy and Confidentiality 13 (2). doi:10.29012/jpc.844. ISSN 2575-8527. PMC PMC10956935. PMID 38515607. https://journalprivacyconfidentiality.org/index.php/jpc/article/view/844. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel12&oldid=63514"