What Is a Data Lake? Architecture, Use Cases, and Best Practices

A data lake is a centralized storage system that holds raw data in its native format until it is needed for analysis. Unlike traditional databases that require data to be structured and organized before storage, a data lake accepts structured, semi-structured, and unstructured data from multiple sources without prior transformation. This article explains how data lakes work, their architecture, how they compare to data warehouses, and the practical considerations for deciding whether to adopt one. The content is written for students, researchers, life-science professionals, and informed general readers who need a working understanding of data lake concepts and their real-world applications.

The Core Concept of a Data Lake

A data lake stores data in its original form, preserving the flexibility to use that data later for purposes that may not have been anticipated at the time of collection. This approach contrasts with traditional data management systems that impose structure before storage. The term "data lake" describes a repository where vast amounts of raw data can be deposited and later accessed for various analytical tasks.

The fundamental principle is separation of storage from use. Data enters the lake through an ingestion process, remains in a raw or minimally processed state, and is only transformed when a specific analytical need arises. This design allows organizations to accumulate data without committing to a particular schema or use case in advance.

The Research Data Framework from the National Institute of Standards and Technology addresses the broader challenge of managing research data across its lifecycle, which includes the kind of storage and access considerations that data lakes are designed to solve. The framework emphasizes the importance of planning for data management from the start of a research project instead of treating it as an afterthought.

Data Lake Architecture

Zone-Based Architecture

Modern data lake implementations commonly use a zone-based architecture, where data moves through distinct stages of processing. A zone reference model for enterprise-grade data lake management was developed after assessing existing zone models against requirements from real-world industry cases. The research found that many published zone models were vague and lacked practical assessment, leading to the creation of a more detailed reference model that proved applicable in enterprise settings.

A typical zone architecture includes four layers: ingestion, storage, transformation, and interaction. This structure was used in a hybrid cloud data lake architecture for clinical and genomics data, where the layers supported integration of genomic test results from multiple vendors. The implementation served 149 clinicians across 31 disease groups and stored 240 TB of data on 5800 patients at a monthly cost of approximately $350, demonstrating that zone-based designs can be cost-effective even for substantial data volumes.

The zone approach addresses a key inefficiency of raw-only storage. Storing only raw data is inefficient because the same processing steps must be repeated for many applications. By keeping data in different degrees of processing, organizations can reuse transformation work across multiple analytical tasks.

Ingestion Layer

The ingestion layer handles the intake of data from external sources. This layer must accommodate diverse data formats and delivery mechanisms, including batch uploads, streaming data, and API-based transfers. In the CEBA environmental data platform, ingestion supported heterogeneous scientific data related to environment and agricultural research, with a distributed JSON-based search engine enabling near real-time querying of wireless network data.

A critical aspect of ingestion is metadata capture. The CEBA project established a scientific consensus that data should be qualified with at least three pieces of information: when the data was collected, where it was collected using geographical coordinates, and what the data represents through metadata. This minimum qualification standard ensures that data remains interpretable after ingestion.

Storage Layer

The storage layer holds data in its raw or minimally processed form. Storage decisions include whether to use on-premise infrastructure, cloud services, or a hybrid combination. The hybrid cloud data lake architecture stored genomic data in the cloud while synchronizing with vendors' storage, allowing independent clinical sites to access the same data through a governance-controlled workflow.

Storage costs are a practical consideration. The same study reported that storing 240 TB of genomic data cost approximately $350 per month, a figure that illustrates how cloud storage economics can make large-scale data accumulation feasible for organizations of varying sizes.

Transformation Layer

The transformation layer converts raw data into forms suitable for analysis. This layer is where data quality controls, standardization, and enrichment occur. The framework for operationalizing and automating data governance proposed a set of metadata artifacts that allow automatic execution of data governance processes, addressing challenges in systematically ingesting, transforming, and integrating data from heterogeneous sources.

Transformation in a data lake differs from traditional extract-transform-load processes because it occurs on demand instead of before storage. This approach, sometimes called extract-load-transform, preserves the raw data while creating transformed versions only when needed.

Interaction Layer

The interaction layer provides access to data for end users and applications. This can include query interfaces, visualization tools, and application programming interfaces. The GeniePool genomic database used a cloud data lake architecture to provide access to next-generation sequencing data through a REST API and a user-friendly website, making thousands of samples and their associated attributes available to clinicians and researchers.

The interaction layer must balance accessibility with security. Access control mechanisms ensure that users can only reach data they are authorized to view, which is particularly important in domains like healthcare where patient data requires protection.

Data Lake vs Data Warehouse

The distinction between data lakes and data warehouses is a common source of confusion. A comparative evaluation of data management architectures analyzed clinical data warehouses, clinical data lakes, and clinical data lakehouses using the FAIR principles and the big data 5 V's of volume, variety, velocity, veracity, and value.

The evaluation found that data warehouses offer strong data governance, stability, and structured reporting, making them well suited for environments requiring strict compliance and reliable analysis. However, warehouses are limited in real-time processing and scalability. Data lakes offer greater flexibility and lower storage costs but require more technical expertise to implement and maintain.

At a Glance: Data Lake vs Data Warehouse

The choice between a data lake and a data warehouse depends on the analytical needs of the organization. A survey of data lake concepts and architectures confirms that data lakes are designed for flexibility and heterogeneous data, while warehouses prioritize structure and consistency.

Use Cases Across Domains

Clinical and Genomic Data Integration

Cancer centers face the challenge of integrating clinical genomics data from different vendors for oncology operations and research. Traditional clinical data warehouse architectures are costly to construct and brittle, and they do not readily accommodate rapid changes in oncology research. A hybrid cloud data lake architecture addressed this problem by creating a zone-based design with rich metadata enabling patient-based queries and a data governance workflow controlling access.

The implementation demonstrated that data lakes can serve both clinical and research workflows simultaneously. Genomic data stored in the cloud was synchronized with vendors' storage and managed by a governance committee, supporting independent clinical sites with different data requirements.

Environmental Monitoring and Agriculture

The CEBA platform filled a gap for a regional institutional platform to share, search, store, and visualize heterogeneous scientific data related to the environment and agricultural research. The platform used the data lake concept to provide a cloud service for end-users with institutional authentication and open data access.

A distinctive feature of CEBA was its full support for managing geographic coordinates at every stage of data management. The platform also used a comprehensive JSON architecture to facilitate multi-stage data enrichment, demonstrating how data lakes can support domain-specific metadata requirements.

Genomic Database Services

The GeniePool project addressed the challenge of making thousands of next-generation sequencing samples and their corresponding attributes easily available to clinicians and researchers. The pipeline continuously downloaded raw human sequencing data from the Sequence Read Archive, preprocessed it using standard analysis tools, and stored the results efficiently in a cloud data lake.

The resulting web service and API provided direct access to sample information and related studies, offering advantages over existing databases for both clinical and research usage. This use case illustrates how data lakes can transform large raw data archives into accessible analytical resources.

Smart City Systems

An urban intelligence architecture used a data lake to store, integrate, manage, and share the large amounts of heterogeneous data acquired and produced by different digital twin subsystems in a smart city environment. The architecture supported data exchange, workflow management, and information visualization.

The prototype implementation leveraged open-source frameworks and technologies, and tests in real-world settings confirmed that the architecture could efficiently support the deployment and integration of heterogeneous subsystems. This demonstrates the applicability of data lake concepts beyond traditional data-intensive domains.

Fish Farming and Agriculture

A data lake architecture for smart fish farming was proposed to initiate a data-driven strategy in a domain where such approaches had not been widely adopted. The research explored existing big data technologies and proposed an architecture applicable to fish farming, highlighting how big data technologies offer advantages for decision making and prediction use cases.

The agricultural context presents unique challenges, including the need to integrate sensor data, environmental measurements, and operational records. Data lakes provide a way to accumulate these diverse data types without requiring a predefined analytical framework.

Scientific Research Infrastructure

The ESCAPE Data Lake addressed computing challenges in the context of the European Open Science Cloud, targeting particle physics and astronomy facilities. The project focused on developing solutions to handle exabyte-scale datasets, with a shared-ecosystem architecture of services fulfilling needs in data organization, management, and access.

The pilot data lake consisted of several storage services operated by partner institutes and connected through reliable networks, using orchestration tools to manage data organization. A 24-hour full dress rehearsal highlighted the achievements of the data lake model for large-scale scientific collaboration.

Data Governance and Quality Control

Metadata Management

Metadata is the foundation of a usable data lake. Without adequate metadata, stored data becomes an undifferentiated mass that cannot be located or interpreted. The CEBA platform established a scientific consensus around qualifying data with at least time, location, and descriptive metadata, providing a minimum standard for data description.

The framework for operationalizing and automating data governance proposed metadata artifacts that allow automatic execution of data governance processes. This approach addresses the challenge of managing tens or hundreds of continuously evolving data sources producing semi-structured data, which is a common scenario in large organizations.

Governance Processes

Data governance in a data lake context involves controlling the data lifecycle from ingestion through transformation to insight generation. The governance framework was developed in collaboration with the World Health Organization for managing and analyzing data about neglected tropical diseases, demonstrating its applicability in public health contexts.

Governance processes should address data quality, data lineage, access control, and compliance requirements. The comparative evaluation of data management architectures noted that data lakes require more deliberate governance design than warehouses because the raw data storage model does not inherently impose structure or quality controls.

Access Control and Security

Access to data in a lake must be controlled through governance workflows. The hybrid cloud data lake architecture implemented a data governance workflow that controlled access to patient and genomic data, with a governance committee managing the overall data environment.

Security considerations include authentication mechanisms, authorization policies, and audit trails. The framework architecture of a secure big data lake addresses these concerns as a core design element instead of an afterthought.

Practical Implementation Steps

Step 1: Define the Analytical Goals

Before building a data lake, identify the questions the organization needs to answer. The data lake architecture framework emphasizes that a comprehensive architecture should be built on a foundation of clear requirements. Without defined goals, a data lake can become a repository of unused data instead of an analytical asset.

Consider whether the organization needs to support exploratory analysis, machine learning, regulatory reporting, or operational dashboards. Each use case has different implications for architecture design and governance requirements.

Step 2: Assess Data Sources

Inventory the data sources that will feed the lake. This includes identifying data formats, update frequencies, and quality characteristics. The systematic literature review of big data architectures for data lakes highlights the importance of understanding the variety of data that must be accommodated.

For each data source, document the metadata that will be captured, including collection time, source location, and descriptive information. The CEBA approach of requiring at least time, location, and metadata provides a useful minimum standard.

Step 3: Choose the Architecture Pattern

Select the zone architecture that matches the organization's needs. The zone reference model provides a detailed structure for enterprise-grade implementations, while the four-layer model of ingestion, storage, transformation, and interaction offers a simpler starting point.

Decide whether to use on-premise infrastructure, cloud services, or a hybrid approach. The hybrid cloud architecture demonstrated that combining cloud storage with vendor synchronization can support multiple independent sites while controlling costs.

Step 4: Implement Metadata and Governance

Establish metadata standards before loading data. Define the minimum metadata fields, the naming conventions, and the processes for updating metadata as data evolves. The automated governance framework shows how metadata artifacts can enable automatic execution of governance processes.

Design access control policies that align with organizational and regulatory requirements. Document who can access what data and under what conditions.

Step 5: Build the Ingestion Pipeline

Develop ingestion processes that can handle the identified data sources. This includes batch processes for periodic data loads and streaming processes for real-time data. The GeniePool pipeline demonstrates a continuous ingestion approach that downloads, preprocesses, and stores data automatically.

Test ingestion processes with representative data before full deployment. Verify that metadata is captured correctly and that data arrives in the expected format.

Step 6: Establish Monitoring and Maintenance

Implement monitoring to track data volumes, ingestion success rates, and storage costs. The ESCAPE Data Lake conducted a 24-hour full dress rehearsal to validate the data lake model, an approach that can be adapted to smaller-scale implementations.

Regular maintenance should include metadata updates, data quality checks, and review of access controls. The operationalizing data governance framework provides guidance on automating these processes.

Records and Measurements

Data Volume Tracking

Organizations should track the volume of data entering the lake, the storage consumed, and the growth rate over time. The clinical genomics implementation reported storing 240 TB of data on 5800 patients, providing a reference point for understanding the relationship between data volume and analytical value.

Storage costs should be monitored against the value derived from data analysis. The same study reported monthly costs of approximately $350 for the 240 TB implementation, demonstrating that cloud storage can be economical when architecture is designed efficiently.

Query Performance

Measure the time required to access and analyze data in the lake. The natural language query system for Apache Iceberg data lakes reported end-to-end query latency averaging 2.6 seconds on 15.1 million records, with partition pruning eliminating over 90% of scanned data files. These measurements illustrate the performance gains possible with well-designed data organization.

Organizations should establish baseline query performance metrics and track changes as data volumes grow. Degradation in query performance may indicate the need for better partitioning, indexing, or data lifecycle management.

Data Quality Metrics

Track the completeness and accuracy of metadata across the data lake. The CEBA platform established a consensus around minimum metadata requirements, providing a basis for quality measurement.

Data quality metrics should include the percentage of data records with complete metadata, the frequency of metadata updates, and the results of data validation checks. The automated governance framework demonstrates how these metrics can be collected and acted upon automatically.

Cost Tracking

Monitor the total cost of ownership for the data lake, including storage, compute, networking, and personnel. The comparative evaluation of data management architectures noted that data lakes offer cost advantages in storage but may require more technical expertise, which is a personnel cost.

Cost tracking should distinguish between the cost of storing data and the cost of analyzing it. Storage costs are relatively predictable, while compute costs can vary significantly based on analytical workloads.

Common Failure Patterns

Data Swamps

A data lake without adequate metadata and governance becomes a data swamp, where data is stored but cannot be found or used effectively. This failure pattern occurs when organizations focus on data accumulation without investing in the metadata infrastructure needed to make data accessible.

Prevention requires establishing metadata standards before loading data and enforcing those standards through governance processes. The CEBA approach of requiring time, location, and descriptive metadata provides a minimum standard that prevents the most basic form of data swamp.

Uncontrolled Data Proliferation

Organizations may ingest data without clear use cases, leading to storage costs that exceed the value derived from the data. The data lake architecture framework emphasizes building architecture on a foundation of clear requirements, which includes understanding what data is needed and why.

Prevention requires a data lifecycle management process that includes data retention policies, data deletion procedures, and regular review of whether stored data is being used.

Governance Gaps

Data lakes that lack access controls and audit trails can create compliance risks, particularly in regulated domains like healthcare. The comparative evaluation of data management architectures found that data warehouses offer stronger governance than data lakes, suggesting that organizations choosing data lakes must compensate with deliberate governance design.

Prevention requires implementing access controls, audit logging, and data lineage tracking as core components of the data lake architecture instead of as afterthoughts.

Performance Degradation

As data volumes grow, query performance can degrade if the data lake is not properly organized. The natural language query system demonstrated that partition pruning can eliminate over 90% of scanned data files, but this requires deliberate partitioning design.

Prevention requires ongoing performance monitoring and periodic reorganization of data to maintain query efficiency.

Metadata Neglect

Metadata that is captured at ingestion but not maintained becomes stale and misleading. The automated governance framework addresses this challenge by proposing metadata artifacts that enable automatic execution of governance processes, reducing the burden of manual metadata maintenance.

Prevention requires automated metadata management processes and regular audits of metadata quality.

Limitations and Considerations

Technical Expertise Requirements

Data lakes require more technical expertise to implement and maintain than traditional data warehouses. The comparative evaluation of data management architectures noted that data lakes require technical expertise for implementation and maintenance, which can be a barrier for organizations without dedicated data engineering staff.

Organizations considering a data lake should assess whether they have the skills to manage the infrastructure or whether they should use managed services that reduce the operational burden.

Governance Complexity

The flexibility of data lakes comes at the cost of increased governance complexity. Because data is stored in raw form, organizations must implement controls to ensure data quality, security, and compliance without the inherent structure of a warehouse.

The framework for operationalizing and automating data governance provides a path forward by automating governance processes, but this requires investment in metadata infrastructure and process design.

Regulatory Compliance

In regulated domains, data lakes must comply with data protection and privacy requirements. The hybrid cloud data lake architecture implemented a data governance workflow to control access to patient data, demonstrating that compliance is achievable but requires deliberate design.

Organizations should consult with legal and compliance experts when designing data lakes that will store regulated data.

Data Quality Uncertainty

Raw data stored in a lake may contain errors, inconsistencies, or missing values that are not discovered until the data is analyzed. This uncertainty is inherent to the data lake model and must be managed through data quality processes.

The CEBA platform addressed this challenge through multi-stage data enrichment, where data quality improves as data moves through processing stages.

Safety and Regulatory Context

Healthcare Data Protection

Data lakes storing clinical or genomic data must comply with applicable data protection regulations. The hybrid cloud data lake architecture implemented a governance committee to manage data access, demonstrating a governance structure that can support regulatory compliance.

Organizations should implement role-based access controls, audit logging, and data minimization practices to reduce compliance risk.

Research Data Management

Research institutions should align data lake practices with established data management frameworks. The Research Data Framework from the National Institute of Standards and Technology provides guidance on managing research data across its lifecycle.

Researchers should also consult reporting guidelines available through the EQUATOR Network to ensure that data management practices support transparent and reproducible research.

Experimental Design Considerations

For research applications, data lake design should support sound experimental practices. The Experimental Design Assistant from NC3Rs provides tools for planning experiments, which can inform decisions about what data to collect and how to structure it for analysis.

Data lakes that support research should preserve the context needed for rigorous analysis, including experimental conditions, sample information, and quality control data.

Literature and Evidence Access

Researchers using data lakes should connect their data management practices to the broader scientific literature. The NCBI Literature Resources and PubMed provide access to published research that can inform data lake design and analytical approaches.

The editorial on the oral-systemic relationship highlights advances in data architecture that support clinical and population-based investigations, illustrating how data infrastructure developments are relevant to biomedical research.

Professional Escalation Criteria

Organizations should escalate data lake issues to appropriate professionals when certain conditions are met. Escalation is appropriate when:

• Data governance failures create compliance or security risks that exceed the organization's internal expertise
• Query performance degrades to levels that prevent effective analysis despite optimization efforts
• Storage costs grow at rates that threaten the sustainability of the data lake
• Data quality issues cannot be resolved through standard metadata and validation processes
• Regulatory requirements change in ways that affect data storage or access practices

In these situations, organizations should consult with data architects, legal counsel, compliance officers, or domain-specific experts. The comparative evaluation of data management architectures provides a framework for reassessing architecture choices when current approaches prove inadequate.

Frequently Asked Questions

What is the difference between a data lake and a data warehouse?

A data lake stores raw data in its native format without requiring a predefined schema, while a data warehouse stores processed, structured data that has been transformed for specific analytical purposes. Data lakes use a schema-on-read approach where structure is applied when data is queried, whereas warehouses use schema-on-write where structure is applied before storage. The comparative evaluation of data management architectures found that warehouses offer stronger governance and stability while lakes offer greater flexibility and lower storage costs.

When should an organization choose a data lake over a data warehouse?

Choose a data lake when the organization needs to store diverse data types without predefined use cases, support exploratory analysis, or enable machine learning on raw data. Choose a data warehouse when the organization has well-defined reporting requirements, needs strong governance and compliance features, or requires reliable structured reporting. The survey of data lake concepts and architectures confirms that data lakes are designed for flexibility and heterogeneous data, while warehouses prioritize structure and consistency.

What is zone-based data lake architecture?

Zone-based architecture organizes a data lake into distinct stages of processing, typically including ingestion, storage, transformation, and interaction layers. This approach was used in a hybrid cloud data lake architecture for clinical genomics data and is supported by a zone reference model for enterprise-grade implementations. Zones allow organizations to reuse transformation work across multiple analytical tasks instead of repeating processing for each use case.

How much does a data lake cost to operate?

Costs vary based on data volume, architecture choices, and analytical workloads. A clinical genomics implementation stored 240 TB of data on 5800 patients at a monthly cost of approximately $350, demonstrating that cloud storage can be economical with efficient architecture design. Organizations should track storage, compute, networking, and personnel costs separately to understand the full cost of ownership.

What metadata should be captured when ingesting data into a lake?

At minimum, capture when the data was collected, where it was collected, and descriptive metadata about what the data represents. The CEBA environmental platform established this minimum standard through scientific consensus. Additional metadata may include data source, collection methods, quality indicators, and processing history.

How do data lakes support genomic and clinical research?

Data lakes enable integration of genomic data from multiple vendors with clinical information, supporting both operational and research workflows. The hybrid cloud data lake architecture served 149 clinicians across 31 disease groups, while the GeniePool database made thousands of sequencing samples accessible through a web service and API. These implementations demonstrate how data lakes can transform raw genomic data into accessible analytical resources.

What are the main risks of using a data lake?

The main risks include becoming a data swamp without adequate metadata, uncontrolled data proliferation, governance gaps that create compliance risks, performance degradation as data volumes grow, and metadata neglect over time. The automated governance framework addresses these risks by proposing metadata artifacts that enable automatic execution of governance processes.

How does data governance work in a data lake?

Data governance in a data lake involves controlling the data lifecycle from ingestion through transformation to insight generation. The framework for operationalizing and automating data governance was developed in collaboration with the World Health Organization and proposes a zoned data lake architecture with governance processes for systematic ingestion, transformation, and integration of data from heterogeneous sources. Governance includes metadata management, access control, data quality monitoring, and audit processes.

Related Articles

• Choosing a Bioinformatics Master's Program: A Decision Framework
• Birds of a Feather: Understanding Flocking Behavior and Its Benefits
• BAM vs CRAM: Choosing a Read Alignment Format for Research Data
• Data Visualization for Biological Research: Choosing Figures That Preserve Meaning
• Viral Titration Methods: Choosing Between Plaque, TCID50, Focus, and Molecular Readouts

References and Further Reading

• Research Data Framework. National Institute of Standards and Technology.
• EQUATOR Network. EQUATOR Network.
• Experimental Design Assistant. NC3Rs.
• NCBI Literature Resources. National Center for Biotechnology Information.
• PubMed. National Library of Medicine.
• A hybrid cloud data lake architecture supporting the integration of clinical and genomics data.. Health informatics journal, 2025.
• CEBA: A Data Lake for Data Sharing and Environmental Monitoring.. Sensors (Basel, Switzerland), 2022.
• GeniePool: genomic database with corresponding annotated samples based on a cloud data lake architecture.. Database : the journal of biological databases and curation, 2023.
• An Urban Intelligence Architecture for Heterogeneous Data and Application Integration, Deployment and Orchestration.. Sensors (Basel, Switzerland), 2024.
• Injury and obesity differentially and synergistically induce dysregulation of synovial immune cells in osteoarthritis.. Annals of the rheumatic diseases, 2025.
• The Oral-Systemic Relationship: Lessons Learned and the Road Ahead.. Journal of dental research, 2026.
• Hybrid Value-Aware Transformer Architecture for Joint Learning from Longitudinal and Non-Longitudinal Clinical Data.. Journal of personalized medicine, 2023.
• Operationalizing and automating Data Governance.. Journal of big data, 2022.
• Enhancing Clinical Data Infrastructure for AI Research: Comparative Evaluation of Data Management Architectures.. 2025.
• Genetic risk of chronic pain conditions associated with risk of suicide death through an integrative analysis of EHR and genomics data.. 2026.
• Democratizing cloud data lake analytics: natural language access to Apache Iceberg via LLM agents.. 2026.
• Data Lake Architecture for Smart Fish Farming Data-Driven Strategy. Applied System Innovation, 2023.
• ESCAPE Data Lake. EPJ Web of Conferences, 2021.
• ESCAPE Data Lake Next-generation management of cross-discipline Exabyte-scale scientific data. 2021.
• A Zone Reference Model for Enterprise-Grade Data Lake Management. IEEE International Enterprise Distributed Object Computing Conference, 2020.
• Managing Google's data lake: an overview of the Goods system. IEEE Data Engineering Bulletin, 2016.
• Impact of pre-transplant immune checkpoint inhibitor use on post-transplant outcomes in HCC: A systematic review and individual patient data meta-analysis. Journal of Hepatology, 2024.
• Modeling response of water quality parameters to land-use and climate change in a temperate, mesotrophic lake.. Science of the Total Environment, 2020.
• The Data Lake Architecture Framework: A Foundation for Building a Comprehensive Data Lake Architecture. Lecture Notes in Informatics Lni Proceedings Series of the Gesellschaft Fur Informatik Gi, 2021.
• An Overview of Current Data Lake Architecture Models. 2022 45th Jubilee International Convention on Information Communication and Electronic Technology Mipro 2022 Proceedings, 2022.
• Framework architecture of a secure big data lake. Procedia Computer Science, 2023.
• Data Lakes: A Survey of Concepts and Architectures. Computers, 2024.
• Big data architectures for data lakes: A systematic literature review. Proceedings 2022 IEEE 46th Annual Computers Software and Applications Conference Compsac 2022, 2022.

This article is educational and does not replace institutional policy, professional advice, or applicable safety and regulatory requirements.