Laboratories are producing more data than ever, but capturing information doesn't necessarily make it easy to find, trust, or use. As laboratory operations grow more complex, the challenge isn't just managing growing volumes of data. It's making that information accessible and useful to the people who need it.
The challenge is rooted in how laboratory data is structured, how activities and changes are recorded, and how easily users can explore information. These three dimensions of Define, Trust, and Discover shape data discoverability.
This article is the first in a series that explores the challenges in facilitating data discoverability. We’ll start with the broader problem of why laboratory data can be difficult to find, trust, and use. The following articles will take a closer look at each of the three dimensions, what they mean for modern laboratory informatics, and how laboratories can enable them.
Why laboratory data can be difficult to find
The square peg problem: Fitting laboratory operations into a predefined model
The way data is structured determines how easily it can be found and which connections can be explored.
Some LIMS are built around predefined schemas that reflect generalized assumptions about how labs operate and they don’t always match an individual lab’s needs. In these cases, the data model is extended during implementation through custom development to accommodate the lab’s specific requirements. However, this adds complexity and information may end up distributed across structures that weren’t designed to work together, making the relationships between records harder to query and retrieve.
The relationship problem: Connections must be anticipated
Consider a cell and gene therapy batch with an out-of-specification (OOS) result. To investigate, the quality team needs to pull together more than the test result itself. They may need to trace the batch back to its source materials, identify the reagent lots and equipment involved, review associated environmental conditions, and understand which operators performed each step. They also need to identify whether other batches or samples were affected by the same materials, equipment, or process conditions.
In many LIMS, data is distributed across tables, with connections between records established through keys and joins. This works well when the relationships between entities and the queries a lab will need to run are known at implementation time. However, when someone needs to explore a relationship that wasn't accounted for in the original data model, answering the question may require custom queries and complex joins. The information exists, but reconstructing those connections takes time and specialized technical knowledge.
A similar challenge arises when a molecular diagnostics lab needs to understand the scope of a failed run. The team may need to identify other samples processed using the same assay, instrument, reagent lot, or workflow configuration. If those relationships weren't established in the original data model, finding all the relevant records can become a technical exercise rather than a straightforward search.
Laboratories must decide during implementation which relationships to establish and which reporting and querying capabilities to support. But they can't predict every question they may need to ask years later as new assays, products, manufacturing processes, or scientific developments introduce new information needs. When the data model can't accommodate those evolving needs, it can become a long-term constraint on the laboratory's ability to find and use its data.
The IT dependency problem: When adapting and accessing data requires ongoing technical resources
Prebuilt reports and dashboards are useful for accessing information that laboratories regularly need, but they can only answer the questions they were designed to address. As lab operations evolve, the data model and reporting capabilities need to evolve with them, which typically depends on IT resources or others with specialized knowledge of the LIMS, like vendor services teams.
This creates a cycle of ongoing technical dependency:
- - Extending the data model: As laboratory needs change, technical resources are needed to accommodate new data requirements, entities, and relationships.
- - Maintaining reporting capabilities: Existing reports may need to be modified to account for changes to the data model, while new reports and queries must be developed for emerging information needs.
- - Retrieving information: Even with an expanded data model, answering questions outside predefined reports can still require specialized knowledge and custom queries.
- - Supporting end users: Laboratory and quality teams may understand exactly what information they need but lack the technical ability to retrieve it themselves.
Each round of development addresses specific requirements without reducing the underlying dependency.
Why laboratory data can be difficult to trust and defend
Locating information is only part of the issue. Teams also need to trust that the data is accurate and complete, and be able to demonstrate its integrity if questions arise.
Retrieving data through complex, custom queries can create additional trust issues. Laboratory teams may not have the technical knowledge to verify how the results were generated or whether all relevant records and relationships were included, leaving them to rely on someone else's interpretation of the data.
Even when the right records have been retrieved, capturing information doesn't automatically guarantee its integrity. A LIMS that allows records to be modified without appropriate controls, traceability, or preservation of their history can make it difficult to establish that what the record contains accurately reflects what actually happened.
Ultimately, data integrity is about more than capturing and protecting individual records. In regulated laboratory environments, teams need to be able to establish who performed an action, when it occurred, what changed, and why, while preserving the history and context behind the data. This includes maintaining the relationships and provenance needed to understand how records connect and what activities contributed to a result. Without that context, teams may struggle to demonstrate what happened, verify that appropriate procedures were followed, and defend the information they rely on to make decisions.
Why laboratory data can be difficult to use
Even when laboratory data has been successfully captured, retrieved, and validated, that doesn't mean it's easy to use beyond the activity that originally generated it.
Data may be difficult to extract from the system, integrate with information from other sources, or interpret without the context of the application in which it was created. Different systems may use different structures, terminology, and formats, making it difficult to combine information and preserve its meaning. And when the relationships and provenance behind a record aren't readily available, its usefulness for future analysis or other applications can be limited.
This becomes increasingly important as laboratories look to make better use of the data they generate, whether that's supporting new research, improving processes, or enabling cross-system analysis. Having large volumes of captured data isn't enough. The information also needs to be structured, connected, and accessible in ways that support uses beyond its original purpose.
The FAIR data principles (Findable, Accessible, Interoperable, and Reusable) provide a framework for making laboratory data useful beyond its original purpose. Achieving these principles requires more than capturing and storing information. Data must be structured, connected, and retain the context needed for future access and reuse. This makes the underlying data model and architecture essential to long-term data usability.
A different approach to laboratory data
Addressing the challenges of finding, trusting, and using laboratory data starts with reconsidering how that data is structured and connected.
These are challenges the Labbit team experienced firsthand through more than a decade of implementing LIMS in complex, highly regulated laboratory environments. Seeing the limitations of existing approaches led to the decision to build Labbit as a graph-native LIMS.
Rather than organizing information primarily around predefined tables and relationships, a graph-native approach represents laboratory data as interconnected entities and relationships. Samples, materials, batches, instruments, operators, workflows, and results are connected directly in the data model, rather than through relationships that must be reconstructed with complex queries. And as laboratory requirements evolve, new entities and relationships can be introduced without requiring the same degree of restructuring associated with extending predefined data structures.
This foundation supports three important aspects of data discoverability:
- - Define: A data model that keeps pace with the lab. Laboratories can introduce new assays, processes, materials, and data relationships as their operations evolve, without having to anticipate every future requirement during initial implementation. Labbit Designer provides a way to define and extend data structures through configuration.
- - Trust: Records with context and provenance. Records retain their connections to the activities, people, materials, and processes that give them meaning, making it easier to understand and trace what happened. Labbit Activity Logs capture an immutable history of user and system activity, helping teams understand the context behind laboratory records and trust in their accuracy.
- - Discover: Connected information that's easier to explore. Users can follow relationships between samples, materials, workflows, equipment, and results to investigate questions that extend beyond predefined reports. Labbit Explorer helps users search and query laboratory records without relying on IT for every question.
A graph-native architecture doesn't automatically solve every challenge associated with laboratory data. Data still needs to be appropriately modeled, governed, and maintained. But it offers a different foundation, one designed to accommodate relationships and changing requirements rather than relying on a fixed set of assumptions about how laboratory data will be used.
When laboratory data is structured around meaningful relationships and retains its context and provenance, it becomes more useful over time. Teams can explore connections across their operations, identify patterns, investigate issues, and bring information together from different sources. It also creates a stronger foundation for advanced analytics, machine learning, and AI.
The opportunity for laboratories isn't simply to capture more data. It's to make better use of the data they already generate, turning records of past activities into an increasingly valuable resource for operational insight, scientific discovery, and future innovation.
Built on more than a decade of experience implementing LIMS in complex, highly regulated environments, Labbit brings together a graph-native data foundation with tools to define, trust, and discover laboratory information.
Want to see how these capabilities work together? Join us on November 18 for What’s New in Labbit: From Data Design to Traceability and Discovery to explore how Labbit helps teams structure, trace, and discover their laboratory data.
