Explore our thoughts on digital transformation, company updates and announcements, industry news and events, and more.
We are incredibly excited and profoundly grateful to announce the closing of our $80 million Series B which was co-led by Insight Partners and Alkeon Capital.
Over the long pandemic lockdown, I taught some folks Python, Docker, and Kubernetes. I learned some banjo. Lost some weight. Baked a lot of sourdough bread. Joined TetraScience and started learning how to build analytics applets with Streamlit. What did you do?
Dan Roberts, Sho Yaida, and Boris Hanin wrote a textbook called Principles of Deep Learning Theory (due out from Cambridge University Press in 2022, but available in .pdf form at the link) that rigorously explains how deep neural networks (DNNs) work from first principles. Along the way, the collaborators show how DNN aspect ratios (width vs. depth) govern their performance, and advance a theoretical framework and new abstractions for categorizing DNNs, predicting their information flow and representational capacity. They use this framework to prescribe methods for extending DNNs to arbitrary depths and solving challenges like the vanishing gradient problem.
Yaida explains this very elegantly in a Facebook AI Research blog, published in mid-June. To summarize: DNNs are now being used intensively for many kinds of practical work. They're of great interest to biopharma research, where they're being applied in areas as pragmatic as predicting when equipment failures will occur (thus enabling continuous manufacturing with near-zero waste), and as open-ended as searching for hits and optimizing leads across vast virtual databases of candidate small molecules -- doing the fundamental, effortful work of identifying therapeutics of likely value automatically, consuming no human or physical resources. On the bleeding edge of research, meanwhile, machine learning is pushing research beyond the (probably structural) limits of human brainpower and intuition. The well-known AlphaFold project, for example, is advancing use of deep learning to rapidly and accurately predict 3D protein structure from sequence data.
But training DNNs effectively is still largely black art because their behavior differs from that of abstract theoretical models, and can thus be time-consuming and inefficient. And validating the competence of trained models with precision has been effectively impossible because (before Roberts et. al.'s pandemic project, anyway) there was no way to rederive the function a DNN is computing from its trained behavior, or predict it in detail from knowledge of the network's initial state and training arc.
Now this is no longer quite so impossible, or so mathematicians and physicists reviewing the book are hoping. To quote from Yaida's blog: “The book presents an appealing approach to machine learning based on expansions familiar in theoretical physics," said Eva Silverstein, a Professor of Physics at Stanford University. "It will be exciting to see how far these methods go in understanding and improving AI." Yaida's own assertion, central to the blog, is that this work potentially opens the door to what may be a period of rapid, systematic improvements in DNN technology, based on firm principles of physics and math, rather than trial and error. It may also (or so we hope) influence improvements to DNN toolkits that make it easier for scientists with deep understanding of biological problems to design, train, and apply DNNs to help find solutions.
Obviously, we're all going to need to read the book as our next pandemic activity.
A groundbreaking new book, soon to be published by Cambridge University Press, promises to simplify application of deep neural networks and make their inner workings easier to validate.
In Part one of this blog, we discussed some of the reasons DIY data platform projects often fail to deliver promised benefits, or do so at unexpectedly high cost.
To review: building a do-it-yourself (DIY) data solution from non-R&D-focused components means assuming responsibility to select, integrate, and lifecycle-manage all the pieces and parts, and researching, architecting, building, and maintaining all the integrations. That's a tall order, requiring headcount and specialized skills — mostly focused on building and operating and getting data into the platform, and much less focused on extracting maximum value from the data itself.
Making matters worse, there's an "impedance mismatch" between the capabilities offered by generic data components and services (ingestion, transformation, cloud storage and search, etc.) and biopharma infrastructure, workflow, regulatory, and scientific characteristics and requirements. So a DIY project that aims to create a quality solution needs to fill the gap: providing the needed scientific and process knowledge to extract, parse, and enrich data close to its sources (data without context has limited utility), and map data into an ontology/schema that makes it readily findable, accessible, interoperable, and reusable (FAIR).
The result: DIY efforts can easily consume vast resources and compel non-strategic organizational spread, while delivering sub-par benefits: e.g., brittle, inflexible, hard-to-maintain integrations between data sources and targets (logically equivalent to one-off, point-to-point integrations, despite traversing a transformation tier and data lake/warehouse), and aggregated data that's devoid of context and non-schematized, so hard to find and use for automation, analysis, visualization, and discovery.
To meet these challenges requires a different approach. The Tetra R&D Data Cloud represents a fundamental shift in terms of how to bridge life sciences data sources and data targets to accelerate R&D.
Data-centric: treating data as the core asset, providing stewardship of data through its whole life cycle. Tetra R&D Data Cloud is architected to treat data as the continual focus: from acquisition, harmonization, data management, data processing, through to preparing the data for AI/ML and pushing to informatics/automation applications. TDP includes:
This data-centric architecture (plus the data-centric focus applied in building true R&D data integrations) ensures that:
Cloud-native: The Tetra R&D Data Cloud incorporates best-of-breed open source components and technologies (e.g., JSON, Parquet) and popular standards favored by scientists and by life sciences and data sciences professionals (e.g., SQL, Python, Jupyter) in an aggressively cloud-native architecture that ensures easy, flexible deployment, resilience, security, scalability, high performance, and minimum operational overhead, while optimizing to provide lowest total cost of ownership.
R&D-focused: with connectivity, integration and data models purpose built for experimental data at the core. TetraScience has created a large (and growing), broadly-skilled (software development, cloud computing, and life sciences), and disciplined organization, and evolved a mature process for identifying, building, and maintaining a library of fully-productized integrations to biopharma R&D data sources and targets, and also creating data models for common data sets. These integrations (including the associated data models, comprising the open IDS) are purpose-built and tailored to fulfill informatics and data analytics use cases in R&D.
Open and vendor-agnostic, leveraging a broad partner network: TetraScience has partnered and actively collaborates industry’s leading instrument and informatics software providers. This partner network collaborates closely, benefiting all the network members (and TetraScience customers) as our collective ecosystem grows. Partnering this way significantly accelerates integration development and productization, helps ensure integration quality, keeps integrations in sync with product updates, and helps guarantee that integrations fully support high-priority, real-world customer use-cases.
Biopharma can best exploit its most important asset — R&D data — by implementing a purpose-built, end-to-end solution that's data-centric, cloud-native, R&D-focused, and open. Hewing closely to these principles, Tetra Data Platform can help reduce non-strategic organizational spread, letting R&D IT organizations focus on adding value and pioneering new applications that accelerate discovery. At the same time, TDP can deliver to scientists, data scientists and other end-users a self-service, unified data experience — where data experts are in control of processing and data modeling, and can configure, manage, and track dataflows from end-to-end.
Building a platform tuned for biopharma R&D use cases means making it data-centric, cloud native, R&D-focused, and open. (Part two of a two-part series.)
R&D biopharma professionals are on a mission to accelerate discovery and improve human life — shortening time-to-market for new therapeutics. This has occasioned a rapid, industry-wide paradigm shift in how data is understood and valued.
Data is now increasingly seen as having large potential utility and value:
Mastering data can change the game. Biopharma organizations are now laboring to make data work harder, seeking to accelerate discovery and improve business outcomes. Practical uses for aggregated data are all around — in fundamental science, lab automation, resource management, quality control, compliance and oversight (for further examples, see our blog about use cases for harmonized data from Waters Empower Data Science Link (EDSL)). Undiscovered value hidden in data is also becoming a powerful lure — R&D focus is expanding beyond tangible experiments to embrace work done on data directly. Applications for ML range from predictive maintenance on lab and manufacturing equipment to discovering novel ligands within huge small molecule datasets and predicting their biological effects.
Mastering data across a whole biopharma organization is, however, a daunting challenge. Life sciences R&D suffers notoriously from fragmentation and data silos — with valuable data produced (and also entrapped) in myriad locations, formats, systems, workflows, and organizational domains. How can biopharma organizations begin to cope with this mountain of complexity?
We find it helpful to think of each R&D workflow in terms of a minimum quantum of organizational and logical effort. To gain scientific or business benefit, you need to find and move information from where it’s created or resides (a data source) to a system or application that can usefully consume it (a data target).
Some common data sources include:
Data targets, on the other hand, are systems that consume the data to deliver insights and conclusions or reports. There are roughly two types of data targets:
Integrating these sources and targets is seldom simple (we comment on some of the reasons for this complexity, below). In many organizations, moving data from sources to targets remains partly or wholly a manual process. As a result:
Seeking to automate some of these transactions, R&D IT teams often start by struggling to build point-to-point integrations connecting data sources and targets, frequently discovering that their work is minimally viable, fragile, inflexible, and difficult to maintain. We’ve written several blogs (e.g., Data Plumbing for the Digital Lab, What is a True Data Integration Anyway?, and How TetraScience Approaches the Challenge of Scaling True R&D Data Integrations) on the complexities of integration building, inadequacies of point-to-point approaches, and requirements for engineering fully-productized, maintainable integrations.
Frustrating experience with pure point-to-point integrations leads many biopharma IT organizations to swiftly begin considering a second-order solution: building a centralized data repository (i.e., a data lake or data warehouse) and using it to mediate connections between data sources and targets. A common approach is to try assembling such a solution from a plethora of available open source and proprietary industry-agnostic components and services for data collection, storage, transformation, and other functions.
Recent articles from Bessemer Ventures and Andreessen Horowitz described versions of a componentized architecture. Note that none of these components are purpose-built for experimental R&D data.
The challenges we’ve solved with 20+ global biopharma companies have convinced us that there are two major problems with this approach:
Data lakes/warehouses, integration platforms, batch processing and data pipeline systems, query engines, clustering systems, monitoring and observability — none of these components are simple, or “just work” out of the box. Most are flexible to the point where serious configuration effort, experimentation, and best practices knowledge is required to make each component do its job and all components work together well. Serious external tooling (plus skilled operations headcount, training, and planning) is required to make updates, scaling, and other life cycle management operationally efficient and safe in production.
Specialized (but non-strategic) skills required. To execute, you’ll need to assemble teams with specialized skills, each managing as few as one vendor, component, or subsystem of the complete solution, plus architects and project managers to orchestrate team efforts. You’ll need these teams long-term, since you’ll be responsible for maintaining and evolving the full stack. Their skills are critical. But they’re also a cost center — focused on running, integrating, and expanding your platform, but remote from the critical path of accelerating discovery (i.e., extracting value from data).
A data science manager at a global biopharma organization comments, “This organizational spread creates bottlenecks, slows down operations, and in turn, delays data usage. The additional need to ensure that a data ingestion pipeline is GxP-validated further increases this problem — in fact, it might even add an additional organizational unit to the mix! We would like the experts to be able to directly handle their data.”
Architectural goals become compromised. Meanwhile, as teams around the project grow, tensions emerge between the need to deliver minimum viable product quickly and longer-term vision — architecture and data flow can start to get out of sync. The danger is that project focus can begin to dwell on parts of the problem: collecting data, storing it, providing data transformation, harmonizing data from multiple sources — rather than creating an R&D-focused, data-centric solution that can steward the whole life cycle of data, end to end.
This swiftly adds friction. In fact, it can make many important applications impossible. Two examples:
In both examples, merely storing the data, collecting the data, or providing data transformation is not enough. To yield benefits, these key operations need to be architected, implemented, tracked, and surfaced in a holistic way, targeting the end-to-end flow of those particular data sets.
Data is stripped of context, limiting utility. To further elaborate on the need to unify these data operations, data collected without adequate context may be meaningful to scientists that recognize the file, but will be useless for search/query, post-facto analytics, and data science at scale. Without a data processing layer that “decorates” data with critical metadata:
For more detail, see Executive Conversations: Evolving R&D with Siping “Spin” Wang, President and CTO of TetraScience | Amazon Web Services and R&D Data Cloud - Beyond SDMS Functionality.
The “impedance mismatch” between industry-agnostic, “horizontal” data solutions and biopharma R&D is amplified by the complexity of the R&D domain.
Scientific workflows are complex. A single small-molecule or biologics workflow can comprise dozens of sequential phases, each with many iterative steps that consume and produce data. As workflows proceed, they fork, reduplicate, and may transition among multiple organizations — different researchers, instruments, protocols.
Biopharma R&D has the largest variety of instruments and software systems per user of any industry, producing and consuming complex, diverse, and often proprietary file and data types. Distributed research (e.g., collaboration with CROs and CDMOs) adds new sources, formats, and standards, and validation requirements to every workflow. This results in research data locked into systems and formats that make it effectively impossible to validate, enhance, consume, or reuse.
Building effective integrations is EXTREMELY difficult. If an R&D organization builds their own R&D data platform using horizontal components, such as Mulesoft, Pentaho, Boomi, Databrick, or Snowflake, it inevitably also needs to build and maintain all the integrations required to pull data from or push data to instruments, informatics applications, CROs/CDMOs, and other data sources and targets. This last mile integration challenge can easily become a never-ending exercise — where the challenge of creating and maintaining fully-serviceable integrations exceeds the capacity of biopharma IT organizations, and distracts from other, more strategic and scientifically important work. For a closer look at technical and organizational requirements for engineering life sciences integrations, see our blog: What is a True Data Integration, Anyway?
Two strategies are often considered for managing this integration workload:
Neither of these two approaches treats connectivity or integration as a first-class business/product priority, meaning that DIY projects often bog down, failing to deliver ROI in reasonable timeframes.
In our next installment, we’ll discuss four critical requirements for untangling life sciences’ complex challenges around data, and show how fulfilling these requirements enables a solution that delivers benefits quickly, scales effectively, and enables refocusing on discovery vs. non-strategic, technical wheel-spinning. Delivering an effective R&D data cloud platform requires more than just IT/cloud know-how and coding smarts. It requires a partnership with an organization that has deep life sciences understanding, a disciplined process for integration-building, and a commitment to open collaboration with a broad ecosystem of partners.
Why is biopharma R&D data so hard to manage? Why do DIY data warehouse solutions, created from industry-agnostic components, so often fail to deliver desired benefits? (Part one of a two-part series.)
Fragmented, inaccessible data. Manual research workflows and data wrangling that increases the risk to data integrity. Interoperability between the enormous ecosystem of instruments, platforms, and applications that are brittle and failure-prone. All these roadblocks impede biopharma organizations in their mission to accelerate innovation in drug discovery and development.
As organizations move to speed digital transformation and implement robust, future-proofed methods to realize the full value of scientific data, emerging solutions that provide frictionless access to FAIR, (findable, accessible, interoperable, and reusable), data are paving the way to the Lab of the Future.
The infographic below highlights four characteristics of the Tetra R&D Data Cloud that empower biopharma to extract value from their data and unlock the Lab of the Future.
Read on!
Infographic highlighting 4 critical “keys” that biopharma needs to unlock the Lab of the Future.
(This blog is Part 2 of a two-part series. For Part 1, see What is a True Data Integration, Anyway?)
In this blog post, we introduce:
In a previous article, we started defining what we mean by a true R&D Data Integration. To fundamentally shift the R&D data landscape from a point-to-point, project-based paradigm to one that is platform-oriented, productized, and cloud-native, biopharma needs integrations with disparate systems such as lab instruments (e.g., HPLC, mass spec, robotics systems, etc.), informatics applications (e.g., registration systems, Electronic Lab Notebooks (ELNs), Laboratory Information Management Systems (LIMS), and contract organizations (CRO/CDMOs). A true R&D Data Integration must therefore be:
Integrations meeting the above requirements can be extremely difficult to build. Commonly-encountered challenges include:
There is a lot of hand-to-hand combat with each system that needs to be properly integrated. Building a new integration requires deep understanding of actual scientific use cases, how to detect changes, how to package data from the source system, how to harmonize the data to vendor-agnostic and data science compatible formats, and how to push the data in a generic and scalable manner to data consumers.
Building one integration is challenging. The typical complexity of a biopharma — including the sheer number and variety of systems used in their R&D — creates a brand new challenge: how to scale integrations to hundreds of types of data systems and thousands of data system instances while keeping integrations productized, maintainable, and while continuing to meet the above stringent requirements for true integrations.
Such variations are inevitable in the real world. All the iterations required to deploy, test, and harden thousands of variant integrations make data integration one of the most painful challenges biopharma faces in their digitization journey. Here are some examples of frequently-encountered variations that must routinely be accommodated:
As mentioned above, biopharma companies typically have hundreds of disparate kinds of data sources and targets, and may be operating many instances of each. Historically, biopharma has relied on two approaches for integrating these many data sources and targets together:
Neither of these approaches has solved the fundamental problem with integrations in a scalable way. Why does TetraScience think we can do so?
We want to be the first to acknowledge that there is no magic or silver bullet. Integrating all the data sources and targets for a large biopharma R&D organization is hard work. However, TetraScience has evolved and is successfully implementing a process that breaks the integrations logjam and will enable biopharma organizations to better leverage the benefits of data, automation, cloud and analytics.
We approach the challenge from five angles:
To build true R&D data integrations, vendor collaboration is crucial. A vendor-agnostic business model and purely data-oriented positioning is critical. Tetra R&D Data Integration connects products in the ecosystem without any other agenda except for providing stewardship of data. At TetraScience we take this very seriously. We believe the R&D data should freely flow across all data systems to ensure biopharma can get the most out of its core asset.
We stand by this core belief. We do not make hardware, we do not build informatics or analytics or workflow applications. We feed data into whatever tools customers and partners want to use, whether this is Dataiku, Data Robot, Spotfire, Biovia, IDBS, Dotmatics, or Benchling — enhancing these tools’ capabilities and value. We collect and harmonize data from any data source, whether ThermoFisher, PerkinElmer, Agilent, or Waters instruments.
At TetraScience, we don’t just have one sub-team focusing on integration. Instead, we treat integration as a company-wide core focus, leveraging participation from the entire organization. Here are the stages of our integration factory line:
Prioritization, Use Case Research, and Prototyping
Build and Productization
Documentation and Packaging
Feedback and Further Collaboration with Customer and Vendors
This factory line model ensures that integrations are prioritized to meet customer needs, engineered with partner feedback and that high-quality integrations are delivered in a repeatable, predictable way. Acquired knowledge and best practices are shared across our entire organization, and we leverage patterns/lessons learned from one integration to inform subsequent efforts.
Simply having an internal engine or process is not sufficient since integrations depend highly on customer use cases and integration endpoints, and on knowledge sharing with vendors.
We believe in working with biopharma organizations to identify the best integration strategy to set them up for long-term success in digital transformation. We often find that the right approach is not always the most straightforward.
For example:
As we work with each customer, we outline and discuss trade-offs among different approaches and share with the customer what we have learned from the rest of the industry. We also work with customers to help them better articulate their data science and visualization use cases, which will in turn inform the right data model to harmonize their data.
In collaboration, we turn a multi-year effort into bite-sized tasks, enabling consistent progress. Scientists who may, in the past, have been burned and burdened by IT projects that have been hugely distracting without yielding much tangible benefit can achieve immediate value and provide feedback.
We believe in partnership with vendors, defining value, and creating abundance, together.
As a vendor-neutral integration provider, TetraScience promotes forward-looking partners, introduces use cases to our partners, provides feedback to partners on their data formats and software interfaces, and introduce them to analytics-related use cases — for example, helping an instrument manufacturer leverage harmonized data and rapidly expand their offering into the application or analytics layer.
As a result, vendors leverage TetraScience to build out better data interfaces and establish their analytics and cloud strategy. Yes, their data can now be accessed by customers without their proprietary software: this can feel a little scary. But vendor-neutral data handling is already an unstoppable trend. On the other hand, because the vendor is typically the expert in their own data and use cases, they are well positioned to explore new possibilities in the visualization, analytics and AI/ML layer which they can build out on top of Tetra Data Platform. Instead of building their own vertical and vendor-specific data stack, vendors can now accelerate their efforts to create value in the application and analytics layer, while benefiting from a vendor-neutral integration layer (which can also provide data from other ecosystem products).
TetraScience’s focus on integration has also helped shape and influence our product design and strategy. Tetra Data Platform is crafted to help our team and customers create and maintain true R&D Data Integrations rapidly, at scale. Some related functionalities include:
Behind the positioning, process, and product is a team dedicated to this mission and vision. Anyone who has tried to tackle this problem will quickly appreciate the diverse expertise needed to get the job done. Imagine the skill sets behind just one single integration, leveraged in the Waters Empower Data Science Link (EDSL), video and blogpost:
Deep expertise introduced from these four kinds of backgrounds, coupled with obsessive attention paid to training and knowledge transfer, forges a unicorn team that is positioned to tackle such a challenge.
As a reference, more than 60% of the team that is driving the integration design and data modeling have life science-related PhDs. They have deep understanding of scientific processes, data engineering/science and hands-on experience using these scientific instruments and informatics applications.
To scale the number of productized integrations, the organization must be obsessively focused on the integrations and all the nuances associated with building a true R&D Data Integration.
This necessitates a big financial commitment over a long period of time, since TetraScience will need to dedicate significant resources to investigate, prototype, build, document, maintain, and upgrade each integration. Scale also allows us the luxury to remain pure-play and focus only where we are uniquely positioned to deliver value. That’s part of the motivation and thesis of our most recent funding round. To read more about our funding announcement, please see: Announcing Our Series B: The What, When, Why, Who, and Where.
True R&D Data Integrations are the foundation for life sciences organizations to digitize their workflow and move towards a more compliant and data-driven R&D process. These integrations are the lines that connect the dots; they form the network that all participants can leverage and benefit from by focusing on their unique science and business logic. Integrations define the substrate where innovation can thrive based on the harmonized data sets that flow freely across whole organizations.
Each integration can be challenging and hundreds of such integrations represent a challenge this industry has never solved before. Without true R&D Data Integrations as the connective tissue, scientific R&D processes move at a pace that is significantly slower than other industries and fail to keep up with the demand of discovering, creating, and marketing life-changing therapies.
We believe it’s the right time to solve the integration challenge, once and for all.
Integrations are challenging. Here's how TetraScience meets the challenge: by leveraging community, disciplined process, product architecture, a multi-skilled team, and capital investment. Part 2 of a series.
Perhaps you learned the scientific method in high school: problem, hypothesis, experiment, analyze data, draw conclusions. Industrial scientists across the scientific and technological landscape have streamlined this process into the Design, Make, Test, Analyze (DMTA) Loop. You start with a design, run your experiments, collect and test samples, then analyze the data and use the insights derived to iterate on the next design. Electronic Lab Notebooks (ELNs) and Lab Information Management Systems (LIMS) are arguably two of the most crucial systems used in the Design and Analyze phase of the DMTA cycle.
Let’s craft an analogy — An ELN is like a storybook, with a distinct beginning, middle, and end. Often, though it depends on your domain, we begin with a picture of what you hope to achieve. For chemists, it’s a reaction scheme with the predicted end product. For biologists, perhaps it’s a specific animal model of disease or a protein structure. For pharmacologists, it’s a target assay or endpoint.
As ELNs are “experiment-oriented,” they focus on experiment results and functions like an “Evernote for science labs.” These are generally more unstructured and flexible, allowing the end user to dictate how to structure their work and affirm success.
A LIMS, on the other hand, is “just the facts, ma’am": it’s sample-oriented and focuses more on barcode tracking, workflow management, and handling analytical results performed on groups or lists of samples. LIMS typically enforces a rigid structure and is less free-form than an ELN.
Let’s zoom out and consider the informatics landscape in biopharma R&D. Few would disagree that challenges begin to mount: data complexity increases and systems fragment. Workflows are held together with brittle, point-to-point integrations. Labs and even individual scientists produce heterogeneous data streams. To introduce some order into this otherwise chaotic data landscape, we here at TetraScience tend to apply a mental model to every R&D workflow — we move information and data from data sources to data targets.
Data sources are where valuable R&D data are produced (or entered) by scientists and lab instruments. Some common data sources include:
Data targets, on the other hand, are systems that consume data to deliver insights and conclusions or to generate reports. There are roughly two types of data targets:
Biopharmas make significant investments when selecting ELN/LIMS. It pays dividends to optimize the scientists' experience when using these solutions.
However, one of the major challenges impeding scientific ROI is the tedious busywork of capturing experimental workflow from, and getting data into, the ELN/LIMS. For example:
In summary, major pain points include moving information from the analyze/design to execution (Make/Test) phases of the DMTA loop, and back again.
When following compliance or expecting high data integrity, this problem manifests more severely, leading to second- or third-scientist reviews. When high-throughput experimentation (HTE) is involved or large files are produced, this problem becomes unmanageable due to the sheer size of the data and the number of operations needed. Imagine spending an hour to run your assay and then 2-3x more time to collect, move, transcribe, upload, and review the same data!
That’s why using Tetra Data Platform (TDP) and ELN/LIMS together is the growing trend in biopharma’s digital lab stack — enabling a true “lab of the future” or “digital lab” experience. The scientists design their experiment in ELN/LIMS, bring their experimental design or sample list to the lab for execution, and then get the data back into the ELN/LIMS without worrying about the “plumbing.” Very often, biopharma uses multiple ELN/LIMS depending on the department or data streams. TDP serves as the data exchange layer for multiple ELN/LIMS while remaining invisible to the scientists. We provide background data stewardship: harmonizing, validating, and moving the data to facilitate the Design, Make, Test, Analyze (DMTA) loop at the core of every scientific process.
Just like almost everything else in life, execution starts from the planning and design. The experimental work starts in assay design or as a request to measure a list of samples (sometimes called a batch). Using TDP, scientists can automatically send experimental designs and transfer batch information or sample lists to instrument control software like Waters Empower, ThermoFisher Chromeleon, or AGU SDC.
Once the scientist finishes executing an experiment, TDP can automatically collect the data, harmonize, validate the data, and then push data into the ELN/LIMS. Sometimes, scientists will search and retrieve the data from the TDP and then import into ELN/LIMS to start their analysis.
Save time and ensure data integrity. Leveraging TDP as the data exchange layer between analysis and execution eliminates manual input of design parameters or sample identifiers to instrument control software as well as the need to manually enter data back into the ELN/LIMS, saving scientists valuable time, preventing compliance issues related to manual transcription, and eliminating tedious second- or third-scientist review by enabling a validated workflow.
Enable data science. Importantly, the automated integration allows ALL scientifically-relevant data to be collected, stored, and queried through the TDP, enabling other data science oriented tools to leverage the experimental data and providing rich data sets for future analysis (data that scientists may wish to ingest into their ELN and LIMS).
Project agility and time-to-value. With TDP focusing on the data (exchange) layer, biopharma organizations now have one throat to choke in terms of bridging the gap between data sources and targets, simplifying project complexity, and shortening time-to-value. TetraScience is responsible for maintaining and upgrading productized integrations and moves in conjunction with ELN/LIMS vendors during rollout.
Our biopharma clients and partners often ask us: “Why wouldn’t an ELN or LIMS just interface with instruments directly? Wouldn’t that be more efficient?”
If you work for an “early-stage” organization with limited data, a lab under construction, or your assays and syntheses change often, this may not be a bad idea. In fact, many ELN/LIMS providers enable features for tabular data import...or your scientists can just manually transcribe the data into/out of ELN/LIMS.
However, if your life sciences company has reached a certain scale — remember, ELN/LIMS core focus is not connecting data sources and targets — very obvious disadvantages will surface when ELN/LIMS are the “connective tissue” of the data layer:
Every day, more ELN/LIMS providers leverage TetraScience to gain a foothold in the cloud-first data landscape and partner with us to drive synergistic product value between our systems.
Linked below are documents describing some real-world data integration examples with industry leading providers, including bidirectional (pull/push) data exchange, showing the full DMTA cycle brought to life and written in data.
In this article, we share fundamental drivers behind the growing trend of combining the relative strengths of the Tetra Data Platform (TDP) with ELN/LIMS and learn how 1 + 1 = 4 for any biopharma organization looking to accelerate its R&D.
TL;DR If you are performing one of the above roles, we invite you to read this whitepaper and explore why traditional approaches to solving the problem of data proliferation, data silos, and end-to-end data and lab automation frequently fail or miss the mark. You will learn how an R&D Data Cloud offers a better approach to scientific data management and value extraction.
R&D data represents a huge and largely untapped store of value for biopharma organizations. Mastering data accelerates discovery: it lets you do science better, collaborate more smoothly, broaden pipeline, negotiate regulatory hurdles, and get new therapeutics to market faster. It lets you leverage and/or build applications — including AI/ML — that grant scientific and strategic insight, enable course-correction, improve quality assurance, and help automate away manual steps at the bench.
Doing this, however, requires a new category of solution that treats the meaning and significance of R&D data as a priority, gives data a genuine life cycle, and then takes responsibility for that life cycle (for ensuring data’s validity and helping extract its full value) end-to-end. Enter: the R&D Data Cloud.
Our new whitepaper, (aptly enough) called What is an R&D Data Cloud? — identifies four characteristics mandatory for such an optimal solution: it must be R&D-focused, data-centric, cloud-native, and open.
The table below highlights how a purpose-built solution for life sciences R&D fuels innovation and what significant gains can be achieved based on your organizational role:
Whatever your biopharma R&D focus, if you’re seeking to derive maximum long-term value from R&D data, please check out our whitepaper, What is an R&D Data Cloud? And if you’re ready to see a real R&D Data Cloud in operation and talk more about how it can help you accelerate discovery, please contact us for a demo.
What does it take to implement an end-to-end, cloud-native solution for unlocking and extracting value from your R&D data? A guide for decision-makers, scientists, and R&D IT.
.svg){kind=icon}
Last month, Tetra’s Chief Scientific Officer Mike Tarselli, joined John Conway, Science and Technology Visioneering, 20/15 Visioneers for a webinar to discuss the growing momentum in life sciences R&D to replatform experimental data to the cloud. The two debated challenges surrounding data generation and management, explored the need for future-proofed, data-centric approaches to digital transformation, and advocated for why FAIR (Findable, Accessible, Interoperable, and Reusable) data and processes have become de facto industry standards.
The webinar focused on digitalization and cloud replatforming initiatives, time spent on manual data wrangling and lab connectivity, and the reality of data FAIRness in life sciences R&D. In addition to an interactive debate between speakers, audience engagement was encouraged and the responses provided key insights into the current state of their digital data initiatives and highlighted why implementing these initiatives now are more critical than ever before.
The blog highlights these insights a little further down — you can also check out the webinar recording.
But before we dive too deep into the vast ocean, some context...
“Big Data” was first coined by John Mashey in 1987 to quantify large volumes of information. As technology advanced since the late 1900s, (to my fellow Millennials, take a beat and let “late 1900s” sink in for a moment…), the velocity of data generation has exploded across industries, especially in healthcare and life sciences. As Dell EMC reports:
“Healthcare and life sciences organizations have seen an explosive healthcare data growth rate of 878% since 2015.”
It’s estimated that by 2025, over 175ZB (zettabytes) of data will be generated worldwide. It’s a number so big, that wrapping your brain around the concept and truly understanding just how big, is pretty challenging.
That’s why when researching how big the “Big Data” in life sciences explosion really is, I was delighted to have stumbled upon the National Human Genome Research Institute’s fact sheet on Genomic Data Science where they equate the volume of genomic data being generated to copies of the movie Jaws. Yes, Jaws - Jaws of the “scaring children out of the ocean” fame. That one…
NHGRI states that a single human genome = 200GB of data = ~200 copies of Jaws.
Genomic data, however, is only one piece of the puzzle. Experimental data generated in life sciences runs the gamut of small and large molecules, imaging, proteomics… the list goes on. However, connecting all these disparate data is a challenge due to the fragmented ecosystem of instrumentation and systems in life sciences, which perpetuate data silos. In turn, these data silos cause significant impediments to innovation in R&D - oy vey.
As drug and therapeutic discovery moves more and more into precision medicine territory, other heterogenous, disparate data will be thrown into the mix, for example:
That’s a lot of data.
A lot of data from a vast array of instrumentation, software systems, and informatics applications.
A lot of data locked-in vendor proprietary data silos, requiring manual point-to-point integration.
A lot of data that requires manual wrangling to standardize for more advanced analytics.
So how do life sciences R&D organizations plan for and manage all the considerations around the V’s of Big Data, ensure the FAIRness of their data and processes, all while future-proofing their investments and accelerating time-to-market?
Well...
All this Jaws talk got us thinking - so we sharpened our pencils and did a bit of our own arithmetic.
We asked: If 200GB of data = ~200 copies of Jaws, how many copies of Jaws = 175ZB of data?
The answer: 175 Trillion copies of Jaws.
(Fun fact: 175 trillion copies of Jaws equals 8 quadrillion Great White Shark teeth. Give us a shout out the next time you win trivia at your local watering hole).
Now, we’re not saying that all of the 175ZB of data generated will be experimental R&D data by 2025, but as data generation continues to explode into a massive tsunami, who’s to say that in the next 5 to 10 years, the number won’t be close to it?
Organizations need to ask themselves critical questions as they begin to map out and implement a future-proofed, holistic, data-centric framework to harness the power of experimental R&D data. Questions such as:
Data proliferation, the recent explosion in data creation and the efforts to store and manage the data, has become an all too familiar challenge in life sciences R&D as the volume of both structured and unstructured data continues to grow exponentially.
So how can organizations within life sciences not only manage data proliferation, but actually benefit from the data explosion?
Simple — use cloud-native technologies and solutions that address challenges with a “data-first” mindset and replatform experimental R&D data to the cloud.
As mentioned previously in the post, we polled the audience to get a better understanding of their thoughts on the data landscape, data maturity, and digital data initiatives within their organizations... and we’re sharing some of them below!
For deeper insights to sink your teeth into (har har) and to watch an interactive Q&A session - check out the webinar recording!
33% of the audience has only begun conceptualizing a digital strategy within their organizations, but have yet to implement.
There’s many moving pieces to plan, build, and implement a data-centric digital strategy for the long-term. Not only are there technical considerations, but how do you also rally your organization and gain cultural buy-in?
0% of attendees are committed to being totally on-prem and have no interest in replatforming to the cloud.
Clearly, on-prem has “jumped the shark.” It’s costly, requires lots of resources to run day-in and day-out, and perpetuates data silos. Cloud-native solutions improve collaboration, reduce costs, accelerate innovation, and enhance security and compliance. The COVID-19 pandemic made it abundantly clear that facilitating collaboration across hallways, organizations, and globally speeds discovery.
70% of the attendees spend most, or almost all of their time creating and maintaining data ingestion, integration, and connectivity.
What do you seek to gain from easily accessible and dynamic data? When the focus is shifted away from manual data wrangling, time can be spent focused on advancing scientific discovery — and isn’t that the whole point?
58% stated that productized integrations are fundamental to a future-proofed data strategy.
True connectivity in life sciences integrates the fragmented ecosystem of the latest technologies, solutions, software, instrumentation, and even systems still running on Windows 95. By standardizing and productizing integrations, the larger scientific community benefits from the time and resources repurposed to more meaningful scientific work.
A Tetra Data Integration has to reach a very high bar to even be considered and must be able to automatically acquire, harmonize, centralize, prepare the data, enable data provenance, and then ultimately push data back into determined targets, like ELN/LIMS systems.
0% of attendees said all of their data could be considered FAIR. And 0% have full accessibility to their data.
Ahh...FAIR data, (Findable, Accessible, Interoperable, Reusable). We need it, we want it, we GOTTA have it.
Back in 2020, John guest authored “The Science Behind Trash Data” blog where he stated that up to 80% of data produced is trash - i.e. not FAIR. This shines a spotlight on the necessity for not only the building of foundational frameworks for data generation, but also the ability to contextualize data, and the implementation of automating the full life cycle R&D data, (acquisition, harmonization, centralization, and preparation for data science and advanced analytics).
What is the benefit of data if it cannot be found, easily accessed, or reused?
It’s clear the movement to replatform experimental data to the cloud is gaining serious momentum in life sciences R&D. Organizations are beginning to think strategically about their data initiatives and implement long-term, data-centric approaches to their scientific workflows - and the cloud plays a major role. Benefits of replatforming include future-proofed investments, accelerated time-to-market, enhanced security and compliance, and the facilitation of collaboration.
However, the cloud can only close the gap so much - what is imperative is the organizational and cultural understanding and buy-in as to why replatforming now is so critical. Allow us to leave you with a thought:
“It’s time to take a stance on it. Start taking a real prescriptive approach on your data integrity, on your FAIRness, on your openness in terms of connectivity and yet, maintaining security, then we can all make this work.” - Mike Tarselli, Ph.D., MBA, Chief Scientific Officer, TetraScience
Don’t be scared of the ocean, jump in - we've got you.
Watch the full recording and interactive discussion on the "Why Life Sciences Organizations are Replatforming Their Experimental Data to the Cloud" webinar page.
.png)
Key takeaways from the “Why Life Sciences R&D Organizations Are Replatforming Their Experimental Data to the Cloud” webinar with 20/15 Visioneers.
The essential feature of an R&D Data Cloud is that it gathers all your data in one place: enriching it with metadata, tags, labels, etc., and parsing and harmonizing it using consistent schemas. That’s what gives Tetra Data Platform power to act as a single source of truth: aligning self-similar data so you can compare and analyze it.
The trick is making that both powerful and simple. The 3.1 release of Tetra Data Platform debuts a reorganized search interface sporting (among other improvements) a Google-like full-text search feature that makes it fast, easy, and intuitive to query the data lake, explore and download results, and/or quickly iterate: useful, for example, in developing performant queries for TDP’s more-technical search tools.
By default, the search screen comes up ready to accept typed queries in TDP’s standard search syntax, based on ElasticSearch’s built-in query_string search capability (a good balance of simple and powerful, but sometimes daunting to neophytes). Full-text search can be turned on by flipping a toggle on the search screen (see Illustration 1), then typing into the search box. You can find full, partial, or approximate matches, leveraging your “Google-fu” directly to explore the TDP data lake. Searches can also be refined with Filters, applied using a popdown Options dialog (see Illustration 2).
Matched results are displayed below (by default), with matches highlighted. You can drill down into returned data items directly, examining schema and values, download search results in .csv format, etc. The new release even lets you preview common stored-data formats (e.g., .pdf) right in the webUI. So you have everything you need to get work done, fast.
As you work, your search phrases and filters are combined in an ElasticSearch Query Language query, which you can review, modify, and re-execute directly (see Illustration 3). All TDP search tools — from the simplest to the most powerful — are thus now linked together to enable a natural workflow: useful for ad-hoc checks, quickly browsing and extracting records, learning the more-technical methods of searching, or for developing well-formed queries for programmatic application via the API.
For more on TDP’s growing system of search features, please see our documentation.
Multiple enhancements to search and new EQL affordances make TDP easier and faster for scientists and developers to use. These improvements are complemented by several improvements to quality-of-life for TDP administrators/operators.
Cloud Configuration: We want TDP to deliver value quickly, which means connecting instrument connectors to agents efficiently. WIth release 3.1, admins can now select a connector and create its agent in one place, instead of going elsewhere (i.e., the Data Hub, Data Management or User-Defined Integration screens) to do so. In the same screen, admins can also view agent status and details. Fewer clicks and context-switches lets you wire things up faster, with fewer mis-steps.
System-wide health/status display: Administrators (and users) can now view the health and performance of TDP components and pipelines from a set of tabbed dashboards. Realtime updates means you can easily locate and intervene if agents, connectors, or data hubs are stressed or offline; and quickly ascertain the cause of pipelines running slowly.
TDP version 3.1 updates aren’t all profound — some are just skin-deep, like a newly-refreshed webUI design with contemporary branding and improved information layout. Our documentation has also been improved, both cosmetically and in terms of discoverability: finding information has never been simpler.
We encourage TDP users to update as soon as practical, to take advantage of new search and operations features (plus bug fixes). Among the latter, version 3.1 of TDP updates npm http-proxy-agent, recently discovered to have a vulnerability to man-in-the-middle attacks.
For more information on TDP Release 3.1, please consult the release notes. To see TDP in action, request a demo.
Release 3.1 of Tetra Data Platform adds easy-to-use full-text search, cloud configuration, and a system-wide health dashboard.
In 2007, Nokia ruled the mobile phone market as its category leader. Their flip phones, among the first to support text messaging and limited video, were a worldwide phenomenon. And yet, Nokia hardly realized an emerging threat: Apple was about to release the iPhone, a service-modeled platform that depended on multiple application developers sharing and co-existing in a more open digital landscape. Within six years, Apple outsold Nokia 5-to-1 and went on to be the fastest-adopted device in history.
We foresee a similar paradigm shift in life sciences R&D when comparing legacy, silo-prone data storage and management to an open, cloud-native, data-centric model. In this blog, we will compare life sciences’ traditional data management choice (SDMS) to the emerging R&D Data Cloud.
Let’s first understand what is an SDMS and what is an R&D Data Cloud.
An SDMS imitates a filing cabinet using software. It captures, catalogs, and archives all versions of a data file from a scientific instrument -- HPLCs, mass specs, flow cytometers, sequencers -- and scientific applications like LIMS, ELNs, or analysis software. Specialties of an SDMS include rapid access, compliance with regulatory requirements, and specific workflows around data management. It’s certainly an improvement over the ‘90s-era process of maintaining your quality team on paper reports!
Essentially, an SDMS is a file server and data warehouse. Unfortunately, for many organizations an SDMS ends up as a "black hole" for experimental data that's carelessly tossed in and quickly forgotten.
The R&D Data Cloud embraces several fundamentally different design and architectural principles compared to SDMS.
First, it is data-centric; instead of just focusing on storing the data, it focuses on the full life cycle of the data and full stack data experience, including data acquisition from disparate sources, data harmonization into vendor agnostics format, data processing, and pipelining to facilitate data flow, data preparation and labeling for data science.
Data does not get stuck here, the goal is to present and deliver the data to the best-of-breed applications that data can be analyzed.
Second, it is cloud-native. Instead of treating the Cloud as just another data center, it leverages cloud services natively for traceability, scalability, security, and portability into private clouds.
Let's compare the two by first understanding the challenges life sciences R&D is facing.
Data volumes in biology, chemistry, materials science, agriculture, and other common R&D organizations continue to explode. The zettabyte era, a measure of total data which began in 2016, will have already expanded 175 times by 2025. Systemic complexity, data heterogeneity and interface discrepancy increase as biological targets become tougher to drug and regulations increase. Rising complexity and data volume present difficulties for legacy systems - outmoded data structures, physical storage limitations, and equipment obsoletion contribute to a trend we’ve observed: R&D organizations are moving away from Scientific Data Management Systems (SDMS) and towards cloud-based or cloud-native solutions.
Now consider the current capabilities of Scientific Data Management Systems (SDMS) and how perceived limitations might impair critical innovations instead of facilitating an open, interactive data future.
SDMS solutions traditionally rely on files exported from instrument control/processing software. However, labs are full of data sources that are not in the form of files; for example, blood gas analyzers, chromatography data systems, etc. These data sources require sophisticated and non-file based connections such as IoT-based or software-based programmatic integration.
Below is a short analysis of file-based integration used in SDMS solutions versus programmatic integrations used by the Tetra R&D Data Cloud.
Once the data is brought into the SDMS, then the SDMS faces a scaling issue. None of the existing SDMS solutions are cloud-native, they are largely on-prem or use cloud storage simply as another data center. This poses two major challenges:
Challenge 1: Difficulty upgrading and maintaining on-prem SDMS
An on-prem SDMS typically requires multiple modules: Oracle databases, application servers, and file storage. Every upgrade requires changes in every module; a non-trivial effort.
A cloud-native architecture enables fully automated upgrade / deployment via infrastructure as code and rolling updates, and can continue to leverage the continuous innovations introduced as these infrastructure platforms evolve.
Challenge 2: Big R&D data
Did we mention zettabytes? As R&D becomes more complex, chemistry and assay outputs on the 100MB scale are giving way to proteomes, genomes (GB), images (TB), and exome maps (PB). Since cloud-native solutions rely on the elasticity and scalability of cloud storage, R&D organizations no longer need to worry about expansion or tedious upgrades.
Cloud-native infrastructure allows tiered storage, providing more flexibility to classify the storage layer to optimize for cost and availability. If you’re not going to access microscopy images for a while, park them in Glacier instead of purchasing extra server racks or hard disks.
Beyond the on-prem vs cloud-native architecture, the R&D Data Cloud differs from SDMS in another fundamental way: SDMS supports very limited data flow or processing since it’s largely an archival dumping ground. Data flow grinds to a halt.
Without these capabilities, SDMS cannot accommodate the dynamic and sophisticated data flow required by modern R&D organizations. Consider a common R&D workflow:
Flexibility is key; R&D organizations should also be able to easily submit the data to multiple destinations such as both the ELN and LIMS (and any other data targets) as their process requires. To accomplish this, simple archiving inside an SDMS is not enough. Configurable data processing enables metadata extraction from the data set, proper categorization with user-defined terms or tags, harmonization of data into vendor-agnostic formats, data integrity checks, and further initiates the submission of the data to downstream applications.
The R&D Data Cloud has elevated the strategic importance of data engineering and integration through cloud-native and Docker-based data pipelines. A user can configure data processing after exploring the data, reprocess the files using another data pipeline, and create their own customized data extraction. They can also merge data from multiple sources, dynamically perform quality control or validation of the data sets, and integrate the data into other informatics applications such as ELN/LIMS.
Users of the R&D Data Cloud will be able to develop such data processing pipelines completely based on their own business logic by creating python scripts in a self-service fashion.
In short, the R&D Data Cloud fundamentally assumes that data should flow and that this flow merits equal consideration to data capture and data storage. The data flow reinvigorates the siloed and stale experimental data and enables fully automated workflows.
SDMS solutions’ static nature makes them largely closed systems; simply putting data together in one place does not make the data discoverable, queryable, or ready for data science and analytics.
To truly leverage the power of the data, it needs to be properly labeled and categorized, and its content needs to be properly extracted. To support API-based queries and data analytics, data needs to be properly prepared, indexed, and partitioned. After all, data scientists can’t do much with a binary file!
The R&D Data Cloud introduces the concept of Intermediate Data Schema files, aka IDS files, which you may find helpful to understand via the following analogy.
In a nutshell, think about your lab as a big warehouse, where there are multiple parcels of different content, shape, weight, and color (like the data produced by your lab instruments, their software, your CRO/CDMOs, and other data sources). These parcels are heavily packaged in their own unique way, and when you have too many parcels, it becomes difficult to find the ones you need. You can't compare the content within each of these parcels, or make any meaningful observation beyond, “these are all very different things.”
Now imagine that each parcel comes with attached IDS metadata, which describes the parcel’s content in a consistent manner. With IDS, it’s much easier to find what you need, since you do not need to unpack each parcel - the IDS makes searching and finding what you need much more efficient.
You can also leverage the IDS’s content consistency to compare different parcels; for example:
Data curation (labeling, categorization, content extraction, harmonization, indexing, partitioning) requires the data be put through a configurable and orchestrated processing layer, which SDMS does not have and simply is not designed for (see previous section, Issue 3). This processing layer is fundamental since data is never ready to be queried or explored without proper curation and transformation.
In the R&D Data Cloud, all data is automatically harmonized into a vendor-agnostic file format. By leveraging open and data science-friendly file formats like JSON and Parquet, the data combines with some of the most popular search and distributed query frameworks to provide highly reusable, flexible platforms to view and structure your data as you wish.
Another aspect of an SDMS to keep in mind is, even though an SDMS may provide preview or analysis on one individual run or data set, it is not optimized for aggregated insights and trending or clustering. However, the R&D Data Cloud provides accessible and harmonized data through a common software interface for visualization and analysis tools that act upon massive amounts of data from different sources, produced at different time points.
Combining the cloud-native data lake, Docker container-based data harmonization, and productized data acquisition, the Tetra R&D Data Cloud distinguishes itself from a traditional SDMS, in that the R&D Data Cloud supports:
As cloud-native services offer more features, accessibility, and post-processing options, it’s time to abandon the SDMS “data flip-phone” for the better, more innovative data cloud option. By adopting the R&D Data Cloud ahead of the curve, you position your company for maximal flexibility and derive deeper analytics from more connected instruments and devices, while benefiting from contemporary best-of-breed technologies to handle big data in your lab digital transformation journey.
Follow us for ongoing updates about all things R&D data and other related topics:
In this blog, we compare life sciences’ traditional data management choice (SDMS) to the emerging R&D Data Cloud: an open, cloud-native, data-centric solution for experimental data.
Typically, when startups issue blog posts about their funding rounds, they follow a standard template which talks about their perspective of the financing; one which often omits the perspective of their investors and the basis for their investment.
I’d like to try and summarize the investment thesis for TetraScience, since it has profound implications for all of our stakeholders – customers, partners, employees, investors, and humanity as a whole.
The following is a composite analysis which includes my own decision criteria as an investor, as my fund - Impetus Ventures - invested in the Series A just a few months ago.
Category Kings and Queens dominate in the winner-take-all world of tech economics in which they capture virtually all of a market's mindshare, market share, margin, and market capitalization. Simply put, to the category victor belong the category spoils. Or, in the inimitable words of Ricky Bobby, “If you ain't first, you're last. You know, you know what I'm talking about?”
These market leaders don’t dominate based upon a single distinguishing attribute (e.g., best product), but rather by strategically defining and perfectly aligning their category, product, organization, and ecosystem in furtherance of their category strategy. When executed properly, and in complete harmony, these integrated components generate powerful self-reinforcing value loops and enable the category leader to raise the most capital, attract the greatest and largest talent pools, build the best products, aggregate the most partners, and deliver more value – faster – to its ecosystem, than any potential competitor.
These Kings and Queens are very clever in developing platforms, and sometimes networks, which serve as rocket fuel, driving non-linear growth, resulting in increasing returns to scale and insurmountable competitive moats.
Lastly, and most importantly, by harnessing and harmonizing these components, these Kings and Queens quickly evolve from being technology vendors to leaders of industry movements. The reference example in this regard is Salesforce. While it’s certainly a leading vendor within the CRM market, the real legacy and impact of Salesforce was its pivotal role in inspiring a generational movement to SaaS and the cloud. That category leadership also unsurprisingly led to their dominance within CRM. Ultimately, Category Kings and Queens create abundance for all ecosystem participants, including themselves, whereas subscale tech vendors live or die in a world of zero-sum transactional outcomes.
Pattern recognition is a primary tool of venture capitalists as it enables them to efficiently sift through thousands of investment opportunities per year. There are consistent “DNA markers” of Category Kings and Queens which VCs screen for and once they recognize them, they pursue those startups with uncommon energy. No group understands the power of Category Kings and Queens better than VCs, as they rely on power law distribution economics to generate their returns. Simply put, they only make real money for their limited partners and themselves if they’re able to back the Category Kings and Queens of tomorrow which generate nearly all of their returns.
Unlike me-too vendors, Category Kings and Queens have to contend with many moving parts in building out the category and engendering a movement around them. Orchestrating a category, product roadmap, organization, and ecosystem concurrently is no small logistical feat and requires complete obsession with clarity – strategic clarity, financial clarity, operational clarity, and cultural clarity – to ensure every single stakeholder is speaking the same language and singing from the same hymn sheet.
Investors who ask a startup for their “elevator pitch” are neither impatient nor unreasonable. They’re simply testing startups to determine if they have perfect clarity into who they are, what they do, why it matters, and why it’s different. If they cannot succinctly and consistently convey this, everything downstream – the company’s culture, operations, customer interactions, etc. – is likely a dumpster fire.
Even when startups are discovering greenfields and breaking new product ground, investors want to understand comparable companies and business models to help them analyze the potential shape of the business and inform their valuation assessment. They like to see plausible comps and simple taglines.
At TetraScience, we are maniacally obsessed with clarity on all dimensions. There is no e-staff session, all-hands meeting, or company activity which we undertake in which we don’t tie everything back to our North Star mission, values, and metrics.
Explaining why we exist, who we are, and why it matters is easy:
For investors, knowing that patterns and comps help inform their thesis and valuation, we explain that TetraScience is to Snowflake, as Veeva is to Salesforce - the highly focused vertical domain expert and full stack provider against the backdrop of a horizontal but distracted Gorilla. Like Veeva, TetraScience is expected to emerge as the de facto standard in Life Sciences and then rapidly move into adjacent verticals which possess many of the same lab markers.
Not surprisingly, VCs seek out startups which are addressing enormous markets and capitalizing on transformational technology shifts (e.g., cloud, big data, AI) and secular replatforming trends. Venture capitalists face two major challenges in this regard – with $300 billion going into startups annually, once a new technology trend emerges which can galvanize a market replatforming, there’s likely to be scores of startups competing for the same mindshare and market share and hundreds of VCs competing to fund the same companies. An important reminder here – notwithstanding the size of the market, ultimately it will coalesce around a single Category King or Queen. Given the overabundance of venture capital and the scarcity of Kings and Queens, I borrow repeatedly from The Hunger Games when I root on my VC friends - “May the odds be ever in your favor.”
For VCs and founders alike, this means that they need to identify and take advantage of some market information asymmetry. They have to identify the non-obvious market opportunity which today looks less like an opportunity and more like a niche or a startup quagmire of some type. A market that scares away most of their competitors but, with the right platform, team, and go-to-market model, could yield commercial success and lead to ever-larger market expansion opportunities.
Representatively, today, TetraScience resides at the nexus of two of the most important venture capital investment themes – the movement of the world’s data to the cloud, and the application of cloud computing and artificial intelligence to life sciences and other complex experimental data challenges. This would logically lead one to conclude that TetraScience must have scores of competitors and is facing all of the byproducts thereof – long sales cycles, feature/functionality-based RFPs in which most startups are column fodder, commoditized pricing, and more.
Yet, as impossible as it may seem, TetraScience is the world’s only pure-play R&D Data Cloud company, operating unimpeded and without a direct competitor, and is building wide and deep competitive moats which will make it exceedingly difficult for new entrants to compete. In fact, we have yet to see a plausible competitor in 23 months due to our first-mover advantage, best-in-class cloud capabilities, open platform and network, and deep domain data expertise. Our competition isn’t really competition at all and is composed of internal IT and/or systems integrators/body shops, or end-point vendors who dabble in integration but are focused elsewhere.
How is this possible? Well, prior to COVID-19 this market had been overlooked, underfunded, and underdeveloped by venture-backed startups due to a misguided and/or misinformed view that experimental R&D labs represent a niche market and that these advanced labs, which have historically been technology laggards, wouldn’t move their data to the cloud. As such, founders and VCs alike have instead focused on pure-play software-enabled biotech companies and end-point lab applications.
In reality, these labs represent a large, growing, and underserved market. Global R&D labs spend more than $300 billion ($177B in Life Sciences alone) annually on research and development and we estimate that $15 billion of that Life Sciences spend is focused on contending with their data challenges via manifestly suboptimal approaches. When large pharmas do replatform – as they have in commercial activities and clinical trials – it’s yielded Category Kings and Queens such as Veeva and Medidata, with a combined value of >$50B.
Category Kings and Queens optimize for creating abundance in all they do and avoid unnecessary zero sum outcomes. The bigger that they can make the economic and value pie for the entire ecosystem, the more everyone benefits. In turn, the ecosystem reinforces their commitment to the King or Queen as the de facto standard. Companies and markets rely upon these standard bearers every day as they maintain clarity and consistency for all.
At TetraScience, our product, market, and business model vectors yield boundless expansion opps for us and all of our category stakeholders. Our product strategy, market focus, and business model – i.e., open data platform, Life Sciences, and partner network – combine to serve as a strong and leverageable foundation from which to seamlessly expand into logical adjacencies, resulting in accelerating revenue, competitive moats, increasing returns to scale, continuous innovation for our customers, and endless monetization opportunities for our partners.
We define this as the SEVENS strategy – i.e., stack evolution (SE), vertical expansion (VE), and network scale (NS):
A world of capital and startup overabundance which greatly distorts the signal-to-noise ratio, a news cycle operating with ever greater velocity, and a toxic combination of social media and founder vanity which fuels endless and shameless self-promotion, converge to form a perfect storm of hype.
But in the final analysis, you can’t hype your way to best-in-class metrics and Category Kings and Queens know this. They’re the embodiment of execution and their metrics reflect this. The best VCs also know this and, as Andrew Carnegie would have said were he working on Sand Hill Road, “As I grow older, I pay less attention to what people say. I just watch what they do.”
Thanks to two decades of cloud company data and the amazing work of firms like Bessemer Venture Partners and Meritech who catalog the data and share metrics, everyone now knows what meh, good, great, epic, and legendary looks like for today’s cloud companies.
Since May 2019, when Spin and I reimagined Tetra 2.0 and launched the Tetra R&D Data Cloud, our metrics have been somewhere between epic and legendary with 2020 ARR growing 10x over 2019, and 2021 ARR expected to increase 3x over 2020. Our capital efficiency has been stellar, with a score of >1.3 in 2020 and an expected 1.5 score in 2021. To that point, we raised an $11M Series A in 2020 and had $9M left on the balance sheet when we closed our $80M Series B on March 26, 2021. Our customer acquisition costs are certainly in the realm of legendary as we’ve barely invested in marketing (although that’s about to change) and our customer retention and expansion metrics are epic.
In connection with our $80 million Series B, I never built a “pitch deck” and instead simply gave Insight and Alkeon unfettered access to our 2020 plan, results, and metrics, and our board-approved 107-slide Plan of Record. I wanted them to “see what we do” and not “hear what we say.”
We led with our metrics and not hype, and we were rewarded by an extraordinarily efficient, professional, and rewarding fundraising process.
At TetraScience, our vision is noble, our mission is vital, and we’re passionately committed to being responsible stewards of a global movement to improve and extend human life through AI-based discovery, enabled by the Tetra R&D Data Cloud.
In preparation for this awesome and humbling responsibility, we have been extremely deliberate in designing, organizing, and aligning our category, product, organization, and ecosystem and we have taken nothing for granted in this regard.
We are guided by our mission and enabled by our values and we are assembling the very best and brightest talent from the scientific, cloud, and data science domains.
We have very purposefully built a one-of-a-kind open platform and integrated network which will deliver increasing returns to scale and generate powerful network effects fueling self-reinforcing value-creation and innovation loops resulting in deep and wide competitive moats.
We have catalyzed massive latent market demand and enjoy first-mover advantage and benefit from remarkably strong tailwinds generated by a secular replatforming to the cloud by the world’s most important labs.
In summary, TetraScience possesses all of the DNA markers of a Category King or Queen and today’s $80 million Series B announcement serves as both validation of this and an enabler of it. Evidence once again that category leaders generate self-reinforcing value creation loops and self-fulfilling prophecies.
We are grateful, blessed, and humbled by the commitment of Insight and Alkeon. Now, back to execution.
Patrick
Category Kings and Queens dominate in the winner-take-all world of tech economics in which they capture virtually all of a market's mindshare, market share, margin, and market capitalization.
Spin and I first met in May 2017 at the Harvard Incubation Lab when he and his fellow TetraScience founders were trying to build an Internet-of-Things (IoT) and application startup to help Life Sciences research labs accelerate discovery. The three founders - former researchers from Harvard and MIT - were brilliant, enthusiastic, and passionately committed to their vision. They had assembled early customers and seed capital and were just about to close their Series A funding.
I came away from my all day session with the founders believing that they were potentially on to something important and valuable – i.e., helping the world’s most important research labs accelerate discovery - but like so many startups, they were trying to do too many things at once, a clear recipe for suboptimization, or worse.
In the ensuing months, with every subsequent high-fidelity discussion with Spin, it became more and more obvious to each of us that TetraScience was likely mistakenly focused on the “market noise” and not the “customer signal.”
In other words, while there was endless hype about IoT – the “market noise” - and biopharma companies were of course interested in improving their existing lab operations applications and intrigued by the potential of IoT technology, their most acute pain was felt at the data layer - the “customer signal.”
Despite their critical importance to humanity, these labs remain dependent on 20th century on-prem software stacks, resulting in experimental data silos, limited collaboration, stifled innovation, and materially sub-optimized discovery. Worse, the proliferation of IoT sensors (the “noise”) would only lead to further data fragmentation and isolation. More to the point, TetraScience might have been ironically exacerbating its customers’ data problems if it only focused on IoT.
IoT and improved lab applications will invariably benefit scientists and aid in discovery – and we are strategically committed to enabling our industry partners in this regard - but to get to the required step-function breakthroughs needed to attain the holy grail of AI-based discovery, someone would have to fundamentally reimagine and then solve the data problem.
Spin and I knew that this was simply impossible in the absence of large-scale and clean data sets. Ultimately, without a centralized, cloud-native, and data-centric architecture and well-designed experimental data taxonomies and ontologies, there was no possibility of capitalizing on advanced data science and AI/ML capabilities. We also concluded that to solve the data problem we would have to be the “Switzerland of experimental data” and not compete with the companies that were generating or consuming the data – i.e., instrument manufacturers, ELNs, etc. It was the only way to ensure that everyone in the ecosystem would trust us as the data intermediary. In effect, the Switzerland of experimental data would have one goal - maximize the value of the data.
Spin and I developed a mind-meld on what could and should be built to move the industry forward. Unfortunately, there wasn’t a consensus among the founders and investors, and little resources were devoted to the R&D Data Cloud that we envisioned. Having no formal role in the company but being a devout believer in the idea and a huge fan of Spin’s, I asked him to reach out if the company ever decided to focus on the R&D Data Cloud concept.
In the Spring of 2019, Spin called me to give me the “good” and “bad” news. The good news was that he was now CEO and completely committed to focusing on the R&D Data Cloud. The bad news was that the company’s overall lack of focus had finally taken its toll, and it was out of money and had lost the confidence of its investors and creditors. With no clear financial backing, a rapidly deteriorating balance sheet, and customer and employee attrition spiking, the company would have to shut down shortly or complete a successful and difficult pivot.
Spin and Sal, the two remaining original founders, came to visit me in San Francisco for three days to brainstorm on how to bring the R&D Data Cloud vision to life. Just as importantly, we focused on how to build a company of enduring consequence and value. We had three choices – let TetraScience shut down and begin anew; recapitalize the company and build anew; or build Tetra 2.0 inside of the legal and capital structure of Tetra 1.0. While the latter approach was the most difficult to execute on (i.e., it’s always easier to start with a clean sheet of paper), we felt it was the right thing to do for all legacy stakeholders.
In May 2019, we raised a new $1.5 million seed round for Tetra 2.0, and with a small number of dedicated employees we began to reimagine and rebuild the company from the ground up. While we entered 2020 with only a handful of midsize pharma customers and proof of concepts with large pharmas, we ended the year with 12 of the world’s top 40 pharma companies as customers and successfully raised an $11 million Series A to begin building a leadership team and support these early customers.
Since launching Tetra 2.0 our growth metrics have been simply remarkable, with 2020 ARR growing 10x over 2019 and 2021 ARR growth expected to increase another 3x over 2020. On the heels of these successes, and for the many other reasons cited in today’s press release and accompanying blog posts, we were able to raise a category-defining $80 million Series B round of funding. In connection with our Series B round we finalized my transition to the CEO role and Spin is now our President and CTO. Our partnership will continue as we scale Tetra 2.0 based on our shared values, singular vision, and mutual trust. We are deeply committed to one another and to our stakeholders, and count on each other to help realize the full potential of Tetra 2.0.
It has been a unique, magical, and immensely rewarding Tetra 2.0 journey thus far and we are just getting started. Along the way, we’ve learned an important lesson for any company and for startup leaders around the world: ignore the market noise and focus on the customer signal.
We wanted to share our unique story and express our profound gratitude to those few that believed in us and the pursuit of this vital mission.
Patrick and Spin
Since launching Tetra 2.0 our growth metrics have been simply remarkable, with 2020 ARR growing 10x over 2019 and 2021 ARR growth expected to increase another 3x over 2020.
Data Integration is one of the biggest challenges for the life sciences industry in its journey to leverage AI/ML. Data gets stuck in proprietary, vendor-proprietary and -specific formats and interfaces. Data silos are connected via rigid, one-off point-to-point and unsustainable connections. As the number of disparate systems increases exponentially - thanks to equipment obsoletion, new instrument models, evolving data standards, acquisitions, and a host of other factors - internal maintenance of this spider web of connections quickly exceeds any life sciences org’s internal IT capabilities.
Here, we’ll introduce our definition of a true integration with an R&D data system, in particular with a piece of lab instrument or instrument software. We’ll also explain why our audacious approach - building and maintaining an expanding library of agents, connectors, and apps - can unify ALL pharma and biotech data silos, something that is the foundation for accelerating drug discovery and R&D.
Let’s start from an assumption we believe is well-understood: life sciences R&D data systems are notoriously fragmented and heterogeneous. We’ve touched on this before (post and video).
Systems diverge on:
Do you want clean, curated data sets, with consistent headers, attuned to FAIR standards, auditable, traceable, and portable? The only way to enable AI/ML will be to have high quality data. To achieve this data liquidity, your divergent instrument outputs must “flow” across the system, connecting the disjointed landscape via a vendor-agnostic open network.
So what is TetraScience’s definition of a true R&D Data Integration, that enables automation, unites diverse data systems, and enables AI/ML?
A true R&D Data Integration with a particular data system needs to be able to surpass a high bar. It must be:
A true R&D Data Integration must necessarily be “full-stack and purpose-built” — configurable data collection, harmonization to vendor-neutral formats, preparation for analytics consumption, automated push to data targets, and tailored to the system and related scientific use cases — so that scientists and data scientists can access and take actions on previously siloed data in order to accelerate discovery.
A true R&D Data Integration can be achieved via a combination of Tetra agents, connectors, and pipelines depending on the specific data systems. For example:
Important Note: When we use the term true R&D Data Integration, we reject simple “drag-and-drop” of instrument RAW files into a data lake. To meet our criteria and quality standards, we must contextually transform source data into a harmonized format, like JSON. These integrations are differentiators for the Tetra Data Platform; to us, if you’re moving files without true parsing and interpretation, no value is added.
Most life sciences data integrations are performed by LIMS and SDMS software, which need to bring data from different sources in ELN/LIMS for tracking and reporting, and to SDMS for storage. LIMS and SDMS rely on two major methods:
While these may be viable options, they are far from optimal for an organization trying to upgrade to an Industry 4.0 motif. Consider the following scenarios:
ELN, LIMS and SDMS have been traditionally relying on file export from the instrument for the majority of their integrations with the instruments and instrument control / processing software.
Extraction from source systems is insufficient to claim true integration. For example, imagine a data scientist has access to thousands of .pdfs from a Malvern Particle Sizer, or thousands of mass spec binary files from Waters MassLynx, or TA instruments differential scanning calorimetry (DSC) binary files; these formats can’t unlock the value of the data and impact R&D.
Other than the file name and path, these binary files are essentially meaningless to other data analytics applications. These data need to be further harmonized into our Intermediate Data Schema (IDS), based on JSON and Parquet, to truly allow any applications to consume the data and R&D teams to apply their data science tools.
TetraScience has taken on the challenging, audacious stance of building out, maintaining, and even upgrading sophisticated integrations; we believe this to be a first in the life sciences data industry, which has long suffered from the vendor data silo problem:
The R&D Data Cloud and companion Tetra Integrations are entirely designed to serve the data itself, liberating it without introducing any proprietary layer of interpretation. If your software can read JSON or Parquet, and talk to SQL, you can immediately benefit from the Tetra Integration philosophy.
Our cloud-native and Docker-based platform allows us to leverage the entire industry’s momentum to rapidly develop, test, and enhance these integrations with real customer feedback. Rapid iteration and distribution of consistent, reproducible integrations across our customer base introduces more use cases, more test cases, and more battle-tested improvements for the entire scientific community.
Check out some of our Tetra Integrations, and request an integration for your team right on that page. We're always interested in hearing from you!
We introduce a definition for proper integration with an R&D data system, in particular with a piece of lab instrument or instrument software. Our audacious approach - building and maintaining an expanding library of agents, connectors, and apps - might unify ALL pharma and biotech data silos.
Our previous post (The Digital Lab Needs an Intermediate Data Schema (IDS): a First Principle Analysis) has established the need for an intermediate data file format for Digital Labs and explains why we chose JSON + Parquet. Now let’s dive deeper into its use cases and discuss what an IDS is intended for, and what it’s not intended for.
In a nutshell, think about your lab as a big warehouse, where there are multiple parcels of different content, shape, weight, and color (like the data produced by your lab instruments, their software, your CRO/CDMOs, and other data sources). Because these parcels are heavily packaged in their own unique way, when you have too many parcels, it’s really difficult to find the ones you need. You can't compare the content within each of these parcels, or make any meaningful observation beyond “these are all very different things.”
Now imagine, each parcel has a sidekick called IDS, attached to each cardboard box, describing the parcel’s content in a consistent manner. With IDS, it would be much easier to find what you need, since you do not need to unpack each parcel and you can just search through the sidekick.
You can also leverage the sidekick's content consistency to compare different parcels; for example:
Hopefully the analogy above is helpful. Now let's move from physical packages in a warehouse to data "packages" in a life sciences company. In more technical terms, IDS is a vendor-agnostic, data science-friendly file format that captures all the scientifically meaningful and data science-relevant information from the vendor-specific or vendor-proprietary file formats produced by a fragmented lab data source ecosystem.
IDS serves multiple important functions: data search, data flow/liquidity and data analytics, which we'll discuss a bit below.
With an IDS, data scientists can leverage API-based or full text search, enabling them to quickly locate an instrument RAW file. As with the package analogy, all data fields are acquired and indexed.
Data can now flow to third-party systems without requiring each of these systems to parse the vendor-specific file formats. This fundamentally breaks down internal data silos and enables more seamless information sharing among instruments, informatic applications, analytics tools and contract organizations (CRO/CDMOs).
The majority of existing lab informatics software solutions were designed as Windows-based on-premises applications. For example, in order to analyze Mass Spec data, a scientist would drag and drop 20-100 RAW files into their favorite analysis software program, spend hours processing the data, and generate a report. This workflow unnecessarily consumes time, and limits the potential for data reuse and sharing.
Now, imagine you need to analyze data using big data technologies like Hadoop, Spark, or others. You wouldn’t be able to effectively use those big data tools while manually managing RAW files. However, IDS (JSON + Parquet) makes big data analytics possible, and the Tetra Data Platform will store, partition and index the IDS files in anticipation of such use cases.
Not at all. IDS is not a replacement of the vendor-specific formats. Organizations need always to save these RAW files, such that scientists can:
IDS makes it easier to find the RAW file and provides large-scale data analysis much efficiently since the RAW file does not need to be opened. Just like the Parcel and Sidekick analogy, the sidekick is not meant to replace the parcel; only to improve its use. In fact, the Tetra Data Platform will first ingest RAW data and then trigger RAW to IDS conversion or harmonization using data pipelines.
This is essentially a variation of the question above, but usually asked in the context of experimental data management.
Let’s first define “archive.” In the context of experimental R&D data, an instrument typically produces “RAW” data - the points, ramps, intensities, depths, counts, and response factors produced by the detector or sensor - which is processed by instrument control/analysis software to produce “Analysis Result." Since sometimes the “Analysis Result” is saved in the same “RAW” file; for the purpose of this article we'll call this RAW data. RAW data is most often present in a vendor-specific format, vendor proprietary format, or non-file-based data system.
For example:
Archive of RAW data means creating a backup from the instrument software or analysis software as a file, stashing it somewhere, and then, when needed, restoring back to the original system, as if the data has never left the source system. (AWS S3 Glacier deep archive is a popular, secure, durable, and extremely low-cost Amazon S3 cloud storage service for data archiving and long-term backup).
Thus, the answer is: No, IDS itself isn't intended for long-term archival.
In most cases, it’s not possible to convert a vendor-proprietary and often binary format into JSON and Parquet, and then be able to re-import the data into the source system without loss of information.
However, the goal of IDS is not to capture everything possible in the RAW file, and in this sense it’s lossy. Therefore, IDS files alone are not sufficient to fulfill experimental data archival requirements. However, as described in the previous section, the content in IDS files will serve as an abstraction layer that will greatly augment search, liquidity, and analytics.
Do not get us wrong, we believe data archival is extremely important. GXP Compliance, patient safety, plumbing "dark data" for new insights: in these use cases and more, data archival critically impacts scientific success. The Tetra Data Platform (TDP) archives original instrument RAW files to the cloud with full traceability and data integrity. You can easily restore processed versions and track lineage back to the original instrument or instrument software.
On top of this, having IDS as a harmonization layer makes the archived data much easier to locate and the information stored in these RAW files much more easily accessible. Vendor and third-party binaries can be searched by file name or extension, but TDP's IDS enables users to search on granular fields like experiment ID, user name, method parameter, or instrument serial number; everything is indexed for faster and easier discovery.
For example, take a look at our Empower Cloud Archival App that leverages IDS to help you search your Waters Empower projects archived in Tetra Data Platform:
Hopefully we've helped you understand what happens to your irreplaceable RAW files (we save them!) and how IDS can lead better analytics, facile search, and ready indexing. In other words, IDS provides everything you'll need to track, find, and sort the heterogeneous and invaluable “packages” in your R&D data warehouse.
If you’d like to dive deeper into the Tetra Data Platform, we recommend this whitepaper covering many of its key capabilities.
As always, follow TetraScience for ongoing updates on experimental R&D data and related topics:
%20(1)%20(1).png)
We use an intuitive analogy to help explain the purpose and use cases of our Intermediate Data Schema (IDS) and its relationship with data archival in a life sciences context.
The conversation focuses on major industry trends shaping R&D processes in pharmaceutical and biotech companies, the complex data lifecycle inherent to R&D, and what does the “Lab of the Future” actually mean.
Read the entire conversation on the AWS for Industries: Executive Conversations blog.
AWS for Industries: Executive Conversations blog is a series of conversations held with innovators progressing disruptive technologies in their respective industries, with a focus on discovery, ingenuity, and contributions to healthcare and life sciences.
Highlights from the blog include:
AWS Healthcare and Life Sciences focuses on collaboration with life sciences organizations around the globe to increase the pace of innovation, accelerate development timelines, and ultimately improve outcomes. TetraScience remains committed to our close partnership with AWS and appreciates having our story highlighted.
AWS Executive Conversations highlight disruptive technologies across industries with a focus on ingenuity in healthcare and life sciences. TetraScience President and CTO, Spin Wang, is the latest to be featured.
Marshall Brennan, Scientific Director at SLAS, chats with Mike Tarselli about his birth on a planet far, far away to his rise as Chief Scientific Officer at TetraScience (a SLAS2021 Innovation AveNEW company). Mike discusses his winding journey starting as a pre-med major and eventually careening to his final path - a Ph.D. in Chemistry and the battle scars accumulated from the arduous path to completion. And then hitting the Great Recession!
Mike shares his thoughts on the challenge of “Big Data” in life science R&D, from data generation, management, all the way to visualization, and what organizations at the forefront of discovery seek to gain from implementing holistic approaches to data automation. TetraScience, and the Tetra R&D Data Cloud, covers the full lifecycle of R&D data: from acquisition to harmonization, engineering, and downstream analysis with native support for state-of-the-art data science tools.
.png)
Listen to the New Matter podcast episode, "Helping Scientists Do More," with SLAS's Scientific Director, Marshall Brennan, Ph.D., and Tetra's Chief Scientific Officer, Mike Tarselli, Ph.D. where they discuss the challenge of "Big Data" in life science R&D.
Authors: Evan Anderson, Cheng Han, Mike Tarselli, Spin Wang
Overview
Protein therapeutics are integral to the pharmaceutical landscape. Consider insulin for diabetes, Factor VIII to treat clotting conditions, or monoclonal antibodies against emerging pathogens or cancerous cells: all are protein-based and require orthogonal characterization and purification techniques to more common small-molecule workflows. Fast protein liquid chromatography (FPLC)[1], a common separation technique, utilizes multiple methods to purify proteins based on their size, charge, or affinity to column packing. For this post, we’ll consider the nearly-ubiquitous Cytiva ÄKTA series of instruments, an adaptive protein purification platform. These instruments are controlled by Cytiva UNICORN software, which holds the chromatographic data and associated metadata for each result.
As with many R&D instruments and their control software, accessing the data contained within the Cytiva UNICORN has traditionally been challenging:
Our Data Science Link makes the data inside UNICORN instantly accessible and actionable. Scientists can now perform analyses and identify insights using their preferred data science tools, without manual data wrangling[2].
Image: Data Science Link Overview
Search, Select, Overlay, Evaluate, and Report
Our partners sought to reduce scientist hours involved in manual data transfer, comparison and analysis. On the Tetra Data Platform, all data from UNICORN systems is automatically harmonized. Using data applications and visualization tools like Streamlit, Jupyter Notebook, Spotfire, Tableau and etc., R&D organizations can build interactive applications that enable scientists to streamline search, select, overlay, evaluate and report.
Search
Scientists seek to compare FPLC run results through comparing output chromatograms. They can conduct flexible queries to obtain results of interests. For example, in order to select a column with better performance for a therapeutic protein of interest, a scientist can search by molecules, resins, column diameter and/or start or end date ranges.
Image: Search by multiple terms
Pre-aggregated values from UNICORN results - molecules, HPLC systems and column parameters - permit rapid selection. Scientists can leverage partial name matches to find specific resins and fetch relevant chromatograms.
Select
Among search results, scientists can select all or a subset of the chromatogram of interests.
Image: Surface chromatograms from selected results
After locating the specific data they are looking for, scientists can select the chromatograms (see: elution peak overlay) to overlay and analyze. In the subsequent sections, we will discuss some common use cases in method development, column performance, and fast access to structured and complete experiment data.
Overlay
Chromatographic overlays from multiple runs can help visualize trends in column behavior, or spot anomalies in flow rate under certain conditions. Clear communication is key; interdepartmental reports help analytical staff visually report their optimization studies
However, there’s a fly in the ointment: run start time, injection time, and injection volume can vary by sample. As a result, the chromatograms arrive misaligned on both time and intensity axes. Simple plotting and overlay of the chromatograms together will lead to erroneous conclusions. Normalization, the process of aligning peaks and baseline with awareness of injection volume, time, and column volume, consumes hours of manual effort for process development scientists daily.
If scientists have all the data from Cytiva UNICORN harmonized, centralized and available for query, they can use the injection volume value to normalize the intensity or height of the chromatogram; scientists can use custom set marks defined in the run log to realign the chromatograms. Enabling scientists to align their chromatograms at a setmark such as elution or wash allows them to compare protein mobility - and, thus, method performance - between results.
Image: Perform overlay with auto alignment for peaks and baseline
Image: Align peaks by Elution Start to compare method performance between different results
Image: Perform custom baseline adjustments (see that the y position at x=1170mLs is now at y=0 mAU) for downstream peak integration
Evaluate
Comparison of peak integrations drives rapid conclusions on recovery yields, impurities, or reaction progression without extra clicks or reinterpretation. This allows scientists to go the “extra step” to automating screening runs, calibrating QC runs, or monitoring method development. Once finished, the final visualization will help scientists determine optimal conditions
Image: Perform custom peak integration to evaluate elution efficiency
Report
In any large scientific organization, communications are key to ensuring alignment between large teams operating in parallel functions. As interpretation of data - in addition to manual processes, file conversions, and kludging this into PowerPoint - may take longer than the experiment itself, it’s unsurprising to see scientists dedicating as much or more of their time to reporting and publishing data sets and notebook pages as they do to their science.
In the instance below, scientists can share chromatograms overlay images and peak table results in .csv format so they can be included in emails, presentations or Excel. The .csv results can also be imported into statistical softwares such as JMP(“JUMP”).
Image: Dynamically Zoom in on overlay and save resulting graphs
Applications: Method Development
Identifying the protocol that achieves optimal yield and quality requires iterative method development. Simply, one changes method parameters and compares purification results. Capturing key method parameters systematically leads to highly efficient and transparent optimization. For example, some of these important parameters include flow rate, pH gradient, buffer, pressure and various scouting variables defined by users.
Capturing and tracking run results and associated operating conditions is not only important in method development but also is essential, in the context of Quality by Design[3], to help decision making during scaling up and method transfer.
Achieve the highest resolution size separation in final polishing steps
Every time chromatography is performed, a portion of scientists' material is lost. This may not be an issue if it’s a commodity material, but in a therapeutic context scientists may have lost much of an antibody, protein therapeutic, or oligonucleotide scientists have spent weeks manufacturing and characterizing.
Polishing runs are critical to produce quality therapeutics[4]. After bulk separations and a concentrating chromatography run, the remaining material may still hide among closely-related contaminants like protein isoforms, polymers, n-1 adducts, or other post-translational modifications. Higher resolution obtained during polishing correlates to less expense, minimized use of customized resin, lower chance of rework (and therefore further material loss), and a better chance that the material so derived will meet specifications.
In this instance, chromatographic overlay will quickly allow scientists to:
Flow Rate Scouting
Flow rate, though a simple parameter (units volume through the column / time) controls the theoretical “plates” [5] that the eluent travels through. This defines what maximal resolution can be. Granted, this also depends on the type of chromatography; size exclusion and gel permeation techniques function differently than silica or hydrophobic stationary phases. As a general rule, scientists want the fastest flow rate that their processes can tolerate (this reduces solvent cost and material degradation) while maintaining resolution.
In a given flow rate scouting, a scientist likely conducts several runs at different speeds, with a standard amount of material and standard run conditions, and monitors the peak shape, retention time (where it appears in the spectrum) and overall recovery (area under the curve or physical measurement at end).
Having all UNICORN results available on Tetra Data Platform, scientists do not need to manually open each run and compare on screen. Instead, they can overlay and time-synch chromatograms of interests, while the areas under the curve (AUCs) are pre-calculated. With a liquid handler and auto injector, scientists could in fact then physically automate this process and automate the data analysis using Tetra Data Platform pipelines.
Applications: Column Performance
When transferring methods to an external organization - a CDMO, a collaborator, or another corporate site - it's important to communicate all critical variables. This might include (but is not limited to): column type, size, packing material, flow rate, diffusion rate, material physical properties, pH sensitivity, and many more.
Scientists can plot the performance of the purification across a large number of runs and better understand how column performance changes over time.
Fast Access to Structured and Complete Experiment Data
Check out this video to see how easy it is to set up the Cytiva UNICORN integration with the Tetra Data Platform.
With the data readily available for scientists to manipulate in data science and data analytics tools, they can create more sophisticated analysis, such as
When structured and complete data is made available and data integrity is reinforced, scientific research or process improvements are no longer limited by the functionalities of the instrument control software.
Summary
Cytiva UNICORN protein purification data provide tremendous insights. When scientists can compare current-day runs with historical results thanks to harmonized, analysis-ready data, scientists save time, manual processing headaches, and reach better technical conclusions
Follow our blog, where we will continuously share use cases from our Tetra Partner Network. These demonstrate how to harness the power of harmonized and vendor-agnostic scientific data. Whether your goal is build reports, conduct correlation or causality analysis, or run AI/ML models to discover untold truths, we hope that you will find relevant answers here.
References
Share another data science use case or inquire about the Data Science Link application by contacting us at solution@tetrascience.com or any of the channels below.
For this post, we'll consider the nearly-ubiquitous Cytiva AKTA series of instruments, an adaptive protein purification platform.
Maintaining an environment fit for a cell
Pharmaceutical and biotech organizations globally use carbon dioxide (CO₂) incubators to maintain stable environments in labs working with cells or tissue cultures. Monitoring CO₂ incubators is tricky due to the sensitivity of the CO₂ sensors. The high humidity in incubators may cause drift or failure in the sensors. These deviations may also not be reported on time, causing serious business and financial impacts.
This blog focuses on the direct integration capabilities of the Tetra Lab Monitoring application which facilitates CO₂ incubator monitoring without the use of independent probes. The benefits result in less time to install, eliminated removal of probes before sterilization, and lower upfront costs in the lab.
CO₂ incubator monitoring provides unique challenges
Properly monitoring CO₂ incubators in the lab is crucial to ensure there are no changes in the equipment or environmental changes such as track temperature, humidity, and CO₂ levels.
Monitoring CO₂ incubators is different from monitoring freezers, environmental temperatures, light levels, gas manifold alarms, or other equipment/factors in the lab. Some considerations lab managers and scientists need to keep in mind when monitoring CO₂ incubators are:
By adding more incubators into the lab, more and more overhead is added as well. An average lab can house 10 - 20 incubators with each set of independent CO₂ sensors taking 10-15 minutes to remove and reinstall. The process takes more time if samples need to be moved to other incubators.
Battle-tested CO₂ monitoring in the lab
The Tetra Lab Monitoring application, built on the Tetra Data Platform, is used by the top global pharmaceutical and biotech organizations to monitor a variety of equipment in R&D and GxP labs such as freezers and refrigerators in addition to environmental parameters. The application also tracks temperature, humidity, CO₂, O₂ and agitation levels in incubators.
Sturdy CO₂ sensors are used and equipped with protective filters to keep out humidity for monitoring. The main benefit is that they can be installed in any incubator. The only thing that is needed is access to an independent sensor port. Monitoring this way allows for a uniform solution for all incubators in the lab.
The Tetra Lab Monitoring application simplifies the CO₂ monitoring process by leveraging the data acquisition capabilities of the Tetra Data Platform. We have developed direct incubator integrations that are easy to install and maintain. Now we can pull data from the data output of an incubator - no external sensors necessary.
IMAGE: View of Heracell Incubator USB data port and the real time CO₂ level monitoring via direct integration
When monitoring incubators via direct integration, you can:
IMAGE: View of the agitation rate in RPM for Infors HT Multitron measured via direct integration
To start, we’ve released a direct integration with the following manufacturers and models of incubators:
The integration allows for the monitoring of parameters like CO₂, O₂, temperature, humidity, spinning rate, and water level via data port output from the incubator.
Summary
Supporting the most popular incubators in the Tetra Lab Monitoring application ensures experimental conditions in incubators across biotech and life science labs are stable and lowers the probability of failure. Scientists do not need to worry about the chances of their cell or tissue cultures dying due to improper environments and losing work that took months. Over the years, our easy-to-use and configurable application has made work in labs more efficient. Developing integrations across a variety of lab equipment, and alongside our dedicated customer support team, has saved many organizations like Notable Labs millions of dollars, countless numbers of equipment, and potential losses.
Thanks to its unique ability to integrate with any instruments, TetraScience is continuosly growing the portfolio of direct integrations with CO₂ incubators. Future integrations include ThermoFisher Forma™ Steri-Cult™ CO2 incubator, and ThermoFisher Forma™ Steri-Cycle™ CO2 incubator to name a few. We continuously work alongside our customers and partners to develop new integrations and features. If you have a specific CO₂ incubator that needs monitoring via direct integration, contact us to learn how easy direct integrations can be.
Remote monitoring of CO2 incubators via direct integrations simplifies the process. This results in lesser installation times and lower upfront costs in the lab, and eliminates the need to remove independent probes for sterilization.
Maintaining an environment fit for a cell
Pharmaceutical and biotech organizations globally use carbon dioxide (CO₂) incubators to maintain stable environments in labs working with cells or tissue cultures. Monitoring CO₂ incubators is tricky due to the sensitivity of the CO₂ sensors. The high humidity in incubators may cause drift or failure in the sensors. These deviations may also not be reported on time, causing serious business and financial impacts.
This blog focuses on the direct integration capabilities of the TetraScience Lab Monitoring application which facilitates CO₂ incubator monitoring without the use of independent probes. The benefits result in less time to install, eliminated removal of probes before sterilization, and lower upfront costs in the lab.
CO2 incubator monitoring provides unique challenges
Properly monitoring CO₂ incubators in the lab is crucial to ensure there are no changes in the equipment or environmental changes such as track temperature, humidity, and CO₂ levels.
Monitoring CO₂ incubators is different from monitoring freezers, environmental temperatures, light levels, gas manifold alarms, or other equipment/factors in the lab. Some considerations lab managers and scientists need to keep in mind when monitoring CO₂ incubators are:
By adding more incubators into the lab, more and more overhead is added as well. An average lab can house 10 - 20 incubators with each set of independent CO₂ sensors taking 10-15 minutes to remove and reinstall. The process takes more time if samples need to be moved to other incubators.
Battle-tested CO2 monitoring in the lab
The TetraScience Lab Monitoring application, built on the TetraScience Data Platform, is used by the top global pharmaceutical and biotech organizations to monitor a variety of equipment in R&D and GxP labs such as freezers and refrigerators in addition to environmental parameters. The application also tracks temperature, humidity, and CO₂ levels in incubators.
Sturdy CO₂ sensors are used and equipped with protective filters to keep out humidity for monitoring. The main benefit is that they can be installed in any incubator. The only thing that is needed is access to an independent sensor port. Monitoring this way allows for a uniform solution for all incubators in the lab.
The TetraScience Lab Monitoring application simplifies the CO₂ monitoring process by leveraging the data acquisition capabilities of the TetraScience Platform. We have developed direct incubator integrations that are easy to install and maintain. Now we can pull data from the data output of an incubator - no external sensors necessary.
IMAGE: View of real time CO₂ level monitoring via direct integration
When monitoring incubators via direct integration, you can:
To start, we’ve released a direct integration with the VWR Basic and VWR Symphony CO₂ incubators. The integration allows for the monitoring of temperature and CO₂ via data port output from the incubator. The incubator does not monitor a percent humidity reading, however an external sensor for humidity percentage can always be added.
Summary
Supporting the VWR incubators in the TetraScience Lab Monitoring application ensures CO₂ levels in incubators across biotech and life sciences labs are stable and lowers the probability of failure. Scientists do not need to worry about the chances of their cell or tissue cultures dying due to improper environments and losing work that took months. Over the years, our easy-to-use and configurable application has made work in labs more efficient. Developing integrations across a variety of lab equipment, and alongside our dedicated customer support team, has saved many organizations like Notable Labs millions of dollars, countless numbers of equipment, and potential losses.
In addition to the direct integration with VWR incubators, TetraScience supports also the following list of Incubators
Thanks to its unique ability to integrate with any instruments, TetraScience is continuosly growing the portfolio of direct integrations with CO₂ incubators. Heracell is only the tip of the iceberg. Future integrations include Panasonic Cell-IQ, ThermoFisher Forma™ Steri-Cult™ CO2 incubator, and ThermoFisher Forma™ Steri-Cycle™ CO2 incubator to name a few. We continuously work alongside our customers and partners to develop new integrations and features. If you have a specific CO₂ incubator that needs monitoring via direct integration, contact a solution specialist to learn how easy direct integrations can be.
Remote monitoring of VWR CO2 incubators wia direct integration results in lesser installation times, lower upfront costs in the lab and eleiminates the need to remove independent probes for sterilization.
Authors: Mike Tarselli, CSO, Spin Wang, CEO
Data volumes in biology, chemistry, and materials science continue to explode. This leads to rising complexity for processing workflows: legacy systems just can’t keep up with innovation demand. Holistic data solutions, coupled with data-centric capabilities to enable the full lifecycle of R&D data, bring these glaring limitations to light. Can we stem the data tide?
Open, configurable data solutions with vendor-agnostic connectivity will empower life science organizations to advance discovery and innovation.[1]
Let’s consider how a scientific data management system (SDMS) might impair the critical innovation path instead of facilitating an open, interactive data future.
So many letters, so little time - an SDMS is software acting like a filing cabinet. These capture, catalogue, and archive all versions of data from instruments -- HPLCs, mass specs, flow cytometers, sequencers -- and scientific applications like LIMS or ELNs. The extracted data are stored and handled in context - and process-specific data formats, which usually maintain consistent metadata and a defined structure.
Essentially, it’s a data warehouse with known limitations: potential incompatibility with heterogeneous data landscapes, ingestion of new experimental data, or data prep for downstream analysis tools. This perpetuates a common biotech Achilles’ heel - the dreaded data silo.
Woe #1: Missed connections
An SDMS doesn’t play well with others: no linking of disparate data sources and targets, like devices, external collaborators, or software systems (ELNs, database, etc.).
Open access to more information
The Tetra R&D Data Cloud easily ingests heterogeneous data sources across the R&D ecosystem. By unifying data in the cloud via native connections, scientists are freed from the data yoke.
Woe #2: Wrangling Data
Data harmonization involves converting vendor-specific or proprietary formats, often manual steps today. An SDMS doesn’t have the functionality to automatically harmonize data into query-ready formats or easy application to visualization or analyses.
Standardize, Harmonize
Automatically harmonize across vendors and formats connecting experimental data into a structured open format -- an Intermediate Data Schema (IDS) or Parquet -- enabling data science and Big Data applications. This means disparate sources can finally be united in standard formats, allowing you to glean insights from all data captured. This wrings value from your precious data, no matter where it came from.
Woe #3: Too much static
An SDMS is a stale, limited repository with no customization opportunities to open your data flows. It simply cannot handle the evolving complexity of research projects.[2]
Let it flow
Comprehensive data engineering capabilities will streamline data prep for AI/ML and advanced analytics. Data flows seamlessly throughout the development process and allows for easy iteration. The TetraScience Data Platform allows Pharmas to create their own processing pipelines, configure triggers, view status, files, and automate notifications via a modern centralized dashboard...a literal control nexus for all your operations.
Woe #4: Stuffing the cabinet
Integration limitation with the myriad file formats found in R&D means SDMSs can easily become yet another data silo, eliminating straightforward data management or collaboration.
Declutter and streamline
Automatic centralization of results in the Tetra R&D Data Cloud enables seamless access, ensures data integrity, and allows for secure collaboration anywhere.
Woe #5: You're gonna need a bigger boat!
R&D data is Big Data.[3] On-premise SDMS can’t digest data scale and complexity if organizations are not able to leverage the digital benefits of the cloud. Without the flexibility needed or the ability to scale, innovation plummets. To swim this data lake, you’re gonna need a bigger boat.
Floating in the cloud...on a yacht
TetraScience’s cloud-native architecture provides organizations the right tools to tackle the complexities in R&D. It makes it easy to manage high volumes of data and complicated workflows with access to the data in a secure environment.
Certainly, an SDMS will work for your organization if you only use one data format or just need a place to stash your files. It’s simple, easy, and stable...but also capability limited. R&D data are complex by nature. Complex challenges require novel approaches. Holistic data solutions that are adaptable, flexible, and scalable optimize data management and eliminate data silos. Get rid of outdated systems that perpetuate roadblocks and cause data woes - and say “Whoa!” to the breakneck speed of digital transformation!
Data volumes are exploding. Workflows continue to get more compley Legacy systems and processes can't keep up. All these factors are compounding into one big cluster...
The display on your -80℃, -20℃, or 4℃ cold storage units will almost always say just that - -80℃, -20℃, or +4℃. However, it is not uncommon for discrepancies between the temperature reported on your freezer and lab monitoring systems to arise. For instance, a freezer in the lab will display -80℃, however the monitoring solution reflects -75℃. This blog highlights how fluctuations in freezer temperature are common and other considerations to keep in mind for properly monitoring freezers in R&D labs.
Most freezers and refrigerators have a compressor (or compressors) that cool the unit. The compressor runs when the temperature gets too high, and turns off once the temperature has gotten low enough. The freezer insulation keeps the temperature from rising quickly, even when the compressor is off.
Uniformity generally refers to a state of consistency. In this context, we’re interested in temperature uniformity throughout different locations in the freezer. When analyzing temperature uniformity, temperature readings over time are averaged. Variation due to compressor cycles is not taken into account because while this affects temperature over time, it should affect all locations in the freezers in a consistent way.
In an ideal world, a ULT freezer averages -80℃ on all sides and in the middle. However, in reality, it might be -75℃ at the top, -78℃ at the side, and -82℃ in the middle. The University of California Riverside published a study[1] in 2016 evaluating ULT freezer temperature uniformity and is very helpful in understanding what the temperature distribution can look like.
Image below is a figure from that study which illustrates a typical temperature profile:
Two common reasons why there may be a lack of uniformity in freezers being monitored could be:
Common factors include:
There are two key take-aways to keep in mind when working with freezers in the lab and how to appropriately monitor them for your business needs:
Takeaway 1: If precise temperature matters to your samples, understand the spots in your equipment with variable temperatures and advise scientists appropriately. If you’ve ever accidentally frozen a dozen eggs because you put them on the wrong shelf in your refrigerator at home - the same problem can happen in the lab.
Takeaway 2: For installation and maintenance of your lab monitoring system, be aware of how probe placement might affect the temperature data collected. If you are a TetraScience Lab Monitoring customer, read on for specifics. If not, request a demo to find out how the solution can streamline freezer monitoring in your lab.
Overall, freezer temperature uniformity should not affect the day-to-day usage of your alarm system. Your alert thresholds should be set above the highest average temperature typically seen in your freezer during normal operation.
Understanding temperature distribution is more important during installation or if you need to move, reposition, or replace the temperature probe.
If you are doing self-installation you should be aware of these temperature differences, and take the following steps to minimize issues due to normal temperature variation:
Keep in mind that every model of freezer is different! If you think the temperature you’re recording is too high or low on average, you can always try moving the probe to a different location.
The key takeaway here is not to panic when there is a difference in how temperature reflects when monitoring freezers in R&D life science labs! Fluctuations in the temperature and discrepancies reflected between the freezers and monitoring systems do not equate failure in either system. Knowing these intricacies can help alleviate worry, establish appropriate alert set points to eliminate alert fatigue, and generally bring peace of mind to scientists and lab managers. The key is to employ solutions that are built and battle-tested to support best-practices for how important lab equipment is not only used, but also properly monitored.
Discrepancies in temperature reflected between the freezers and monitoring systems do not equate failure in either system. This blog highlights key takeaways for monitoring freezer temperature.
John Conway of 20/15 Visioneers has an analogy between R&D organizations and a builDing. The capital D is not a typo - he argues that the word is active (builDing) instead of passive (builTing) because it is never really finished. There will always be some kind of upgrade, improvement, enhancement, or repair. He talks about power - electricity and networks that allow for communication. He talks about virtual capabilities like software and advanced analytics. He talks about infrastructure as the critical foundation that protects and allows for proper existence. He also talks about plumbing as the processes and instruments that produce and move data. Here at TetraScience, we think this analogy is spot on, and we are inspired to dive deeper into the concept of "data plumbing."
When you think about plumbing for your home, running water, dishwashers, washing machines, etc. is what what pops into your head. At face value, it doesn't seem too complicated. However, plumbing can be incredibly complex when you think about how it needs to work in a NYC skyscraper, sports stadium, or the New England Aquarium. For biotech and pharmaceutical companies today, data flow in the lab is equally - if not more - complex than the water plumbing systems in those buildings. In the lab, there are heterogeneous instruments - different brands and models producing disparate file formats. There are distributed partners, such as CROs and CDMOs, that are doing outsourced research. Different applications are also found in the lab, such as registration, inventory, ELN, LIMS, and home-grown applications. There are many workflows that scientists are running, different kinds of experiments and assays, and increasingly, different visualization and analysis tools that data scientists are introducing into the ecosystem.
We define lab data plumbing as the collection, cleansing, harmonization, and movement of all lab data.
Just like the plumbing in a building, it can be messy and dirty. It involves the unrestricted flow of a valuable substance, (information or water), through a complex system that can be simple to start, but quickly becomes complicated. This requires special skill sets, tools, and careful design to properly implement.
Let’s consider some examples of data plumbing in today’s lab:
This type of primitive data plumbing is happening every day in every biopharma lab around the world. It isn’t automated, but it is already present - like manually pumping water out of a well instead of simply turning on the faucet.
Using building plumbing as inspiration, let’s think about some design requirements for a modern Digital Lab Data Plumbing system:
These are just some of the parallels we can pull from plumbing in a building. This can inspire to use proper design of a lab data plumbing system.
Of course, labs have their own unique challenges to consider:
Hopefully by now you agree that data flow in the Digital Lab is quite complex and quite important, and deserves a renovation. Just to be safe, let’s put some numbers to the concept.
Let’s go back to the 3 data plumbing examples we talked about: 1) CROs sending a large volume of files that need to be quality checked manually, 2) scientists copy-pasting into notebooks and then manually transcribing into ELNs, and 3) data scientists manually aggregating results. Customers tell us it is common for scientists to spend as much as 10-20 hours per week on these types of manual data wrangling activities.
If we do some quick, back-of-the-envelope math to scale this up to a large organization with thousands of scientists, it could look something like this:
This is a meaningful, sizable, fundamental problem in the lab. In terms of opportunity cost, what could your scientists do with that 1 million hours of productive or uninterrupted time? Could they run 10% or even 20% more experiments?
What could you data scientists do with clean, accessible, prepared data at their fingertips? What is the implication, or rippling effect, of transcription errors or the lack of reported information propagating downstream?
First, plan the data plumbing system for your lab as a first level architecture consideration, not as an afterthought. This does not mean that you have to be building a new lab. For your existing labs, the typical approach is to buy the instrument, buy the ELN, and then figure out how to connect them. In your building, you design the plumbing system knowing that there will be a dishwasher and a sink, even if the exact fixture hasn’t been purchased yet. Same for the lab, you know you will need to move data around, so plan a configurable “message bus” (for our IT readers) that is capable of plugging into a variety of instruments and applications. And then plug them in.
Second, START NOW! Don’t wait. Don’t let scientists and data scientists waste their time on data wrangling. Every little bit helps make a dent in that 1 million hours and $125 million dollars wasted every year. If the job seems daunting, just pick off one small component at a time. You are not in this alone! We are here to help. Follow our blog and our social media for tips, or check out our website to learn more about our data engineering platform that provides the data plumbing for the Digital Lab.
.jpg)
Just like the plumbing in a huge building, data plumbing in the digital lab can be messy and dirty. It's simple to start, but quickly becomes complicated.
As Life Sciences labs continue to ramp up the speed of innovation, standardized management of controls and processes need to be enforced to ensure the reliability, reproducibility, and high integrity of not only all the data produced, but also the processes around monitoring and managing all activities in the labs themselves. GxP quality guidelines and standards are necessary for the safety and integrity of products manufactured - this is especially important in the life sciences industry, as most of the final products are intended for human use.
GxP compliance in organizations includes the ability to ensure all processes and digital data records are trustworthy, reliable, and cannot be manipulated. This includes keeping track of any unusual events detected by systems, like deviations or anomalies across all equipment found in the lab. This information is required to be provided to government agencies, like the FDA. The reports need to include supporting documentation that reflects incidents and that no step in the process was compromised or manually edited. This is necessary to determine whether the level of deviation does not negatively impact the final product and ultimately deem it unsafe for use.
The challenge for many organizations to ensure GxP compliance is having access to best-in-class lab monitoring solutions that automatically export thorough reports required by government agencies to successfully complete audits. By not automating the generation of reports in non-editable formats the task is not only laborious, and at risk of human error, but also does not comply with governmental agency guidelines stating the data and reports cannot be manipulated. By implementing incident reporting features, organizations have the ability to monitor and report on any deviation or anomaly detected by lab monitoring solutions and be able to automate reports. This further enforces GxP and ensures compliance across the organization.
IMAGE: Automatic incident report generated by TetraScience Lab Monitoring application
The Tetra Lab Monitoring application, built on top of the Tetra Data Platform, is designed for GxP labs to enable 21 CFR part 11 compliance through features such as comprehensive audit trails, electronic signature, multi-factor authentication, and others. The addition of incident reporting to the Lab Monitoring application will enable Life Sciences organizations to automatically generate comprehensive incident reports that reflect all deviations detected across equipment in the lab - and at a click of a button. This will save organizations time, resources, and enable their compliance and operational integrity.
The application combines cloud-native and web-based user experience with reliable hardware that supports 5GHz Wi-Fi, cellular, and hardwired connections. Built on infrastructure that makes data accessible and secure, it meets all data integrity requirements necessary.
.png)
The TetraScience Lab Monitoring application now provides comprehensive incident reporting for monitoring and tracking of all potential deviations across equipment in Life Sciences labs.
HighRes Biosolutions designs and builds innovative laboratory automation systems, dynamic scheduling software, and lab automation instruments. Cellario, industry's state-of-the-art lab automation software, enables instrument and robotics scheduling in the lab. Lab automation systems and software generate massive volumes of R&D data that can accelerate therapeutic discovery.
The integration between Cellario and TetraScience automates and streamlines the collection of R&D data generated from Cellario into downstream data science applications and other informatics applications such as ELN and LIMS.
Cellario, with its coupled API layers, is designed to support a wide range of upstream and downstream data integration requirements. Cellario’s RESTful API can be used to integrate with any other software platform. In this case, TetraScience is leveraging Cellario’s publisher/subscriber event APIs to receive data events. In addition to standard data events that every reader creates, end users can easily customize the data stream by using scripts to create data events.
Data is centralized in the Tetra Data Platform and harmonized into the Intermediate Data Schema (IDS)-JSON, which is a structured, vendor-neutral format. Once R&D data is harmonized, it is directly queryable in web API or SQL, and can be further transformed into any format needed. Cellario produced data is now accessible by your favorite data science tools. It can also be combined with other R&D data that customers store in the TetraScience platform for further analysis.
Step 1: Configuration
Our connector was developed in collaboration with HighRes Biosolutions as part of our integration. You can simply configure connection to the Cellario software on the TetraScience platform web interface. No need to kick-off a multi-month customization project, write code from scratch, and then spend even more effort and money to maintain the connection [1].
The product roadmap for this integration includes more features in future releases, such as, filter by event/data types, data selection with a determined time frame. These are based on use cases crowdsourced from Life Sciences companies within the Tetra Network. Continuous platform innovations, like new features and capabilities, are made available to customers regularly.
IMAGE: Configuration of HighRes Biosolutions Cellario software to the Tetra Data Platform
Step 2: Collect RAW Files and Attach Metadata
The first step after configuration is collecting the RAW files. The files are automatically extracted by our Cellario connector and uploaded into the Tetra Data Lake. The connector also collects and attaches important metadata to the files. Metadata and tags are customizable, and often include information about the order, request, plate, Cellario protocol, and/or other relevant metadata. Tagging metadata provides powerful context to integrate data with ELN/LIMS and perform advanced data science and analytics. Sufficient context is one of the foundational steps in FAIR data principles.
IMAGE: Metadata attached to Cellario extracted files
IMAGE: Select Cellario Metadata & Tags
Step 3: Data Engineering + Data Science in the Cloud
After the automatic data collection process, a data pipeline parses the data into IDS-JSON format. The data is now harmonized in the cloud-native data lake. Two immediate benefits of this data engineering are:
IMAGE: Visualization of HighRes Biosolutions lab automation systems usage
IMAGE: Visualization of data produced during a plate reader run
This process enables data and workflows that are accessible and scalable in a secure, cloud-native environment.
Step 4: Inline Cloud-based Data Analysis and DOE
This integration establishes a closed-loop in lab automation and Design of Experiment (DOE) software. There are also APIs to place orders and manage automation systems and Cellario-controlled instruments and devices.
IMAGE: Data automation feedback loop between HighRes Biosolutions and TetraScience
To take it one step further, you can introduce cloud-based in-line analysis and calculation, using interactive data science tools like Jupyter Notebook. The lab automation system now benefits from in-line cloud computation. You can also leverage historical data sets - contributing to the model and instructing the next point to search in the parameter space.
TetraScience + HighRes Biosolutions best-in-class workflow, control, and orchestration solution will no doubt allow scientists to unlock discoveries in life sciences faster. The manual effort associated with data integration and subsequent human error is virtually eliminated - allowing for high integrity and consistency of the data. Leveraging an enterprise-grade and cloud-native platform enables actionable insights in the entire development and discovery process.
.png)
Integration between HighRes Biosolutions' Cellario lab automation software and the Tetra Data Platform provides cloud-based data management and unlocks data science
Author: John F. Conway, Chief Visioneer Officer, 20/15 Visioneers
Trash or Dark Data is collected data that is not being touched or getting secondary use. We are not talking about tracking data or ancillary system data, etc. We are unfortunately talking about R&D data that has come from experimentation and testing, both physical and virtual. This means individuals and organizations are not taking advantage of key decision-making data and information and are missing very valuable insights.
In many R&D organizations, Trash Data has accumulated and can account for upwards of 80% of its known data. (1) , (2)
The interesting part of this conundrum is that it's both structured and unstructured data! If data isn't properly contextualized, it’s probably not going to be reused, hence it becomes Trash Data. So, don’t get fooled with just pushing mis- or uncontextualized data to the cloud, because you will now have Trash Data in the cloud!
Unfortunately, in the year 2020, this is a major problem for R&D organizations. It is telling you that either you have no Scientific Data and Process Strategy, or, even worse, you are not following the one you have written and committed to following! It's also telling you that some of your AI/ML strategies are going to be delayed until the organization solves its major data and process problems. Model Quality Data (MQD), and lots of it, are needed for AI/ML approaches in R&D. And remember, your processes produce the data, so they go hand-in-hand. Data generation processes need to be formulated and established during the initial step of any data project. To mitigate the risk of being inundated with trash data, a foundation with strict requirements of data production and integration need to be established. “Data plumbing” is a critical step that will ensure your properly contextualized data is routed and deposited in the right location.
Another major issue is what to do with legacy data! Based on what was just discussed, my experience has shown that ~80% of legacy data is not worth migrating. The best strategy is probably to leave it where it is and connect to it with your new data integration platform. However, you will determine the value and worth of the legacy data by performing a data assessment through the new platform.
So, how has this happened? How did we arrive at this place where 80% of our hard-won R&D data ends up as trash? The truth is that it comes down to human behavior and discipline. Writing, agreeing, and committing to a Scientific Data and Process Strategy is step number one. However, to take a written agreement and turn it into standard processes that are embedded within the organization, you need a company culture that includes true leadership and a focus in the area of REPRODUCIBLE science. Tactically, it starts with data capture and storage principles. You need a Data Plumber!
R&D organizations are like snowflakes - no two are identical - but there is much overlap in process and types of data generated! Variation is the real problem. Instrument types and various lab equipment with or without accompanying software (e.g. CDS - chromatography data systems), ancillary scientific software like entity registration, ELN (electronic laboratory notebook), LIMS (laboratory information system), SDMS (scientific data management system), exploratory analysis, decision support, Microsoft Office tools, and the list goes on. Hopefully, you have consistent business rules for managing and curating your data, but the chances are this varies as well. What you, unfortunately, end up with is a decidedly unFAIR (see FAIR data principles) data and process environment.
Why did you, a mature R&D organization end up in this position? (Startup Biotechs – BEWARE! Learn from the mistakes of those who have gone before and don’t let this happen to you!) (3). It may be hard to deconvolute, but I think, and this can be up for debate or confirmation, the mindset of “data and processes as an asset” got lost somewhere along the way. Perhaps management and others became impatient and didn’t see a return on their investment. Poorly implemented scientific software tools that were designed to help these problems, compounded the situation. In some cases, environments were severely underinvested in. Taking shortcuts in the overall data strategy, without establishing other foundational steps or processes, is like building a house without a proper foundation. At first, this leads to sagging windows and doors, and a poor living experience with the house. Eventually, the foundation-less house collapses or needs to be demolished. In other cases, churn and turnover in different IT/Informatics and business functions created a “kick the problem down the road” situation. Many times, the “soft” metrics weren't gathered for the repeat of experiments and the time that was wasted in trying to find things and make heads or tails of poorly documented data or experiments. At the end of the day, humans worked harder instead of smarter to make up for the deficiencies.
Imagine you can start to solve this problem both strategically and tactically. Tactically, it starts with business process mapping and completely understanding your processes. The understanding of the detail is an insurance policy for much better outcomes in your journey. As discussed, strategically you need a sound written Scientific Data and Process (SD&P) Strategy that the organization can follow. Tactically, you need to capture your structured and unstructured data in both raw and processed forms. It must be properly contextualized; in other words, you need to execute on your SD&P Strategy. Make sure you are adding the right metadata so that your data is relatable and easily searchable.
This can’t all be done on the shoulders of your scientists. Instead, use smart technology and adopt standards wherever possible. You need to purposefully design the framework for the “data plumbing” in your organization. Both hot and cold data needs to be routed to where it belongs. And... besides an ELN, SDMS, or LIMS, it may belong in a knowledge graph where its true value can be exploited by all personas, like data scientists, computational scientists, and savvy scientists making bigger decisions! When you can accomplish this purposeful routing, you will end the broken pipes which led to data silos and disparate data! Finally, you are on the road to being a FAIR compliant R&D organization! Findable! Accessible! Interoperable! And last, but not least, secondary use of your data - Reusable!
Your organization must make very important decisions about how it is going to guard some of its top assets - propriety data and processes. All R&D organizations need their high-quality science to be reproducible and repeatable. The data and process capture must be exact for this to occur. This means understanding both the instrument integration AND the “plumbing” or shepherding of the data into the right data repositories is critical.
Let’s consider one example. On the surface, an ELN is keeping track of the researcher’s Idea/Hypothesis through to his or her Conclusion. The ELN captures some artifacts of data including images, files, etc. However, in many cases, the ELN does not support the storage of massive amounts of experimental data. Instead, it records a pointer to this data. This “pointer” strategy prevents application data bloat and encourages the proper storage and curation of experimental data. This is just one example where “data plumbing” design comes into play in many medium to large R&D organizations. Having a platform that you can plug into that captures data, instrument, application, and process integration is a high ROI (return on investment) need.
Having worked in this space for thirty years in a plethora of roles, from individual contributor to leading strategy and teams for many years, it became obvious that this is a very big problem and will need true team work to combat. Many bespoke systems have been built, maybe some have worked well, but I haven't seen it myself.
I believe that we are finally able to solve this Trash Data problem once and for all. You need to partner with companies who are taking a platform approach to get into production as quickly as possible. You need partners who truly understand data diversity, contextualization, and FAIR principles.
Every day you don’t have a solution in production, the Trash Data continues to pile higher. The predictions are out there, IBM is estimating a jump to 93% in the short years to come.
The platform needs to be cloud-native to provide the scalability and agility needed for future-proofing. It needs to be enterprise-grade, meeting the security and compliance needs of Life Sciences R&D. It also needs to elegantly handle the complexity of not only the automated collection of data – everyone can do that these days – but also “plumbing” of the data to and from multiple ELNs, LIMS, SDMS, Knowledgebases/graphs for data science tools, etc. We all know that big pharma is never going to be able to consolidate to one provider across the enterprise. And it needs to harmonize all the data – RAW and processed - and significantly reduce or eliminate Trash Data. The platform needs to automate all repeatable tasks and metadata collection/capture to remove the burden from the scientists and improve data integrity. This is a serious endeavor, and one you can't afford to ignore. After all, you don’t know what you don’t know, but even worse, you don’t know what you already should, and you can’t find that experiment or data in your current environment!
About the author:
John has spent 30 years in R&D environments that include Life Sciences, Material Sciences, Computational Sciences, Software, and Consulting. In his last BioPharma role, John was Global Head of R&D IT for AstraZeneca and Global Head of Data Sciences and AI. John started his own Consultancy in late 2019, 20/15 Visioneers, which has been taking off and keeps him busy. To read more of John's thought leadership in R&D Informatics, check out the 20/15 Visioneers Blog.
John F. Conway, Chief Visioneer Officer at 20/15 Visioneers, dives into the subject of Trash Data and its impact on R&D organizations. With thirty years of experience, Mr. Conway believes the problem of Trash Data can finally be solved.
Maintaining an environment fit for a cell
Pharmaceutical and biotech organizations globally use carbon dioxide (CO₂) incubators to maintain stable environments in labs working with cells or tissue cultures. Monitoring CO₂ incubators is tricky due to the sensitivity of the CO₂ sensors. The high humidity in incubators may cause drift or failure in the sensors. These deviations may also not be reported on time, causing serious business and financial impacts.
This blog focuses on the direct integration capabilities of the Tetra Lab Monitoring application which facilitate CO₂ incubator monitoring without the use of independent probes. The benefits result in less time to install, eliminated removal of probes before sterilization, and lower upfront costs in the lab.
CO2 incubator monitoring provides unique challenges
Properly monitoring CO₂ incubators in the lab is crucial to ensure there are no changes in the equipment or environmental changes such as track temperature, humidity, and CO₂ levels.
Monitoring CO₂ incubators is different from monitoring freezers, environmental temperatures, light levels, gas manifold alarms, or other equipment/factors in the lab. Some considerations lab managers and scientists need to keep in mind when monitoring CO₂ incubators are:
By adding more incubators into the lab, more and more overhead is added as well. An average lab can house 10 - 20 incubators with each set of independent CO₂ sensors taking 10-15 minutes to remove and reinstall. The process takes more time if samples need to be moved to other incubators.
Battle-tested CO2 monitoring in the lab
The TetraScience Lab Monitoring application, built on the Tetra Data Platform, is used by the top global pharmaceutical and biotech organizations to monitor a variety of equipment in R&D and GxP labs such as freezers and refrigerators in addition to environmental parameters. The application also tracks temperature, humidity, and CO₂ levels in incubators.
Sturdy CO₂ sensors are used and equipped with protective filters to keep out humidity for monitoring. The main benefit is that they can be installed in any incubator. The only thing that is needed is access to an independent sensor port. Monitoring this way allows for a uniform solution for all incubators in the lab.
The TetraScience Lab Monitoring application simplifies the CO₂ monitoring process by leveraging the data acquisition capabilities of the TetraScience Platform. We have developed direct incubator integrations that are easy to install and maintain. Now we can pull data from the data output of an incubator - no external sensors necessary.
IMAGE: View of real time CO₂ level monitoring via direct integration
When monitoring incubators via direct integration, you can:
To start, we’ve released a direct integration with the HeraCell VIOS. The integration allows for the monitoring of temperature, water level, CO₂, and O₂, (when required), via USB output from the incubator. The incubator does not monitor a percent humidity reading, however when the water in the equipment is low a notification is sent. An external sensor for humidity percentage can always be added.
Summary
Supporting the Heracell VIOS incubator in the TetraScience Lab Monitoring application ensures CO₂ levels in incubators across biotech and life sciences labs are stable and lowers the probability of failure. Scientists do not need to worry about the chances of their cell or tissue cultures dying due to improper environments and losing work that took months. Over the years, our easy-to-use and configurable application has made work in labs more efficient. Developing integrations across a variety of lab equipment, and alongside our dedicated customer support team, has saved many organizations like Notable Labs millions of dollars, countless numbers of equipment, and potential losses.
Heracell is only the tip of the iceberg. Future integrations include Infors HT Multitron shaking incubator, ThermoFisher Forma™ Steri-Cult™ CO2 incubator, and LiCONiC StoreX Series of incubators to name a few. We continuously work alongside our customers and partners to develop new integrations and features. If you have a specific CO2 incubator that needs monitoring via direct integration, fill out our Tetra Lab Monitoring Contact Us form to learn how easy direct integrations can be.
Direct data acquisition and integration for monitoring CO2 incubators results in lesser installation times, lower upfront costs in the lab, and eliminates the need to remove independent probes for sterilization.
Automating lab workflows to remove manual data management will spearhead a new era of therapeutic development
Bioprocessing is important for discovering effective biologics that can be leveraged in the development of treatments and therapeutics. In the first half of 2019, 36% of the new molecular entities (NMEs) approved by the FDA were biologics, up from 29% in 2018 and 26% in 2017. This is a trend that is expected to continue.[1]
However, it is a challenging and expensive problem to figure out. Since 2014, biologic drugs account for nearly all of the growth in net drug spending: 93 percent of it, in fact.[2] The methods, workflows, and APIs (Active Pharmaceutical Ingredients) used by biopharma in the discovery of biologics, and subsequent development and implementation of therapeutics, need to be streamlined for maximum efficiency. This means bioprocessing workflows and data need to be fully automated from data collection to analysis of the data. By automating and connecting equipment and systems, manual tasks and associated human error are eliminated which keep the total cost of ownership (TCO) low.
Anywhere between 20% - 30% of time spent by researchers is wasted on manual data transcription and tedious manual data integration.
In addition to manual data management, bioprocessing data is typically in heterogeneous formats. The data is produced by different lab equipment and systems throughout multiple stages of the workflow. This leads to data silos that are difficult to integrate. These challenges - manual tasks, human error, heterogeneous formats - slow down bioprocess development significantly.
The new era of bioprocessing, known as Bioprocessing 4.0, focuses on the integration and connectivity of lab equipment and systems. This will give scientists access to higher quality data and allow for deeper insights.
Connecting bioprocessing data with disparate life sciences R&D data for further analysis
Unifying BIO-API (or bioprocessing) data with other R&D data produced in the development process will provide scientists with deeper insights that have the potential to accelerate the drug discovery process. AGU’s Sm@rtLine Data Cockpit (SDC) enables the use of sensors and analyzers for the collection, review, and approval of trial results in laboratories. AGU and SDC have over ten years of experience serving top global pharmas in bioprocessing (BIO-API). In that time, they have improved quality, reduced significant costs, and shortened the length of discovery time for both biopharmaceutical companies and the BIO-API industry. The cloud-native and enterprise-scale Tetra Data Platform powers the centralization and harmonization of all R&D data, preparing it for advanced analytics and data science. The partnership not only lowers the total cost of ownership (TCO) and is significantly quicker to deploy than building internally, but will speed up the rate of discovery and development of therapeutics and treatments.
IMAGE: SDC + TetraScience example architecture diagram
Bioprocess data collected through the SDC-TetraScience integration is immediately ready for data science.
Higher data integrity and deeper insights power development
Life sciences, biotech, and biopharmaceutical organizations will reap massive benefits through adopting the concept of Bioprocessing 4.0 in their workflows. The foundation of Bioprocessing 4.0 - the automatic collection, centralization, harmonization, and unification of bioprocessing, BIO-API, and R&D data in a central cloud-native platform - is not easy to achieve. Once fully adopted, Bioprocessing 4.0 will allow scientists to stop wasting time with tedious manual data management. It will reduce human error, keeping data integrity high. Additionally, data silos will be eliminated, allowing scientists to query large volumes of bioprocessing data and providing the ability to reach actionable insights efficiently.
Summary
The partnership between SDC and TetraScience expands the network of connectors and integrations that automates data collection - the first step towards Bioprocessing 4.0. Scientists have the ability to leverage bioprocessing data collected by SDC. The data is uploaded into the cloud, where it is centralized, harmonized, and prepared for advanced analytics and data science, making R&D data in the cloud truly accessible and actionable.
Learn more about the TetraScience and AGU partnership and how bioprocessing data is automatically harmonized and centralized, connecting disparate data silos to activate the flow of data across the R&D and Bioprocessing ecosystem.
Our recent blog post - Data Science Use Cases for the Digital Lab - highlights how scientists are leveraging our network of connections and integrations to truly harness the power of life sciences R&D data. The blog post features seven data sciences use cases crowdsourced from our partners and customers.
AGU's Sm@rtLine Data Cockpit and TetraScience partner to unify life sciences R&D data in the cloud and automate lab workflows to power Bioprocessing 4.0.
Author:
Salvatore Savo, Co-Founder, TetraScience
Since its inception, Tetra Lab Monitoring Application has been assisting the life sciences industry with monitoring of critical equipment. Our best-in-class Lab Monitoring Application is used by top global pharmaceutical and biotech organizations to monitor freezers and CO2 incubators. Over the years we have saved our customers millions of dollars and countless numbers of equipment and in potential losses.
Over the last several months, our team has been working tirelessly to take the product to the next level so that we could also add value to GxP labs. We are excited to announce that our Lab Monitoring Application is now 21 CFR part 11 ready and can enable your lab to be GxP compliant.
For decades, life science organizations have relied on paper based records as the only source of truth. With the advent of electronic records, the life sciences industry had to adopt guidelines to ensure that the digital data could be trusted. The 21 CFR Part 11 regulations define the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records by the Food and Drug Administration (FDA).
These are some of the most relevant new product features and services that we have introduced:
Record Keeping and Auditability
The TetraScience Audit Trail chronologically catalogs events to provide support documentation and history used to authenticate operational actions. These records provide proof of compliance and operational integrity. These are some of the critical elements contained in the audit records for each event:
IMAGE: Example of an Audit Trail report in the TetraScience Lab Monitoring application
Security
In order to enable the highest level of security and to prevent fraud, the TetraScience Lab Monitoring application supports multi-factor authentication. This adds a second layer of security to protect user accounts and personal information. Additionally, users will be asked to prove their identity by entering username and password when performing critical actions. Lastly, administrators have the possibility to require users to re-enter their credentials in case of prolonged inactivity using the dashboard.
Whether you are planning to build a new manufacturing facility or working in an existing one, you need to make sure to use the most reliable Lab Monitoring system on the market to keep your samples safe while being compliant. TetraScience Lab Monitoring combines the best-in-class cloud-based software user experience, with the most reliable hardware that supports 5GHz Wi-Fi, cellular, and hardwired connection, all built on an infrastructure that ensures your data is always accessible and never compromised, thus meeting your data integrity requirements.
Superior User Experience
The Lab Monitoring application is designed to be intuitive and easy to use. Whether you are monitoring one piece of equipment or hundreds of pieces of equipment, you'll be able to seamlessly integrate our monitoring system with your internal workflows.
Customer-centric
We work with you and your QA team through every step of the process, and are always available to assist you. Our modern dashboard includes a live chat feature for communicating with our customer support team in real time when you have questions or emergencies.
Low Onboarding Maintenance Overhead
Traditional monitoring systems require you to manage and configure the alerting system. We do everything for you, from equipment data entry and instrument naming to alert configuration.
TetraScience's Lab Monitoring application is now 21 CFR part 11 ready. This means we can enable your lab to be GxP compliant with features like audit trail, electronic signature, multi-factor authentication, and more.
About AWS and the event:
AWS Healthcare and Life Sciences focuses on collaboration with healthcare providers, public health organizations, government agencies, and life sciences businesses around the globe to increase the pace of innovation, accelerate development timelines, engage with patients, and ultimately improve outcomes. The free virtual event focused on how healthcare and life science organizations are accelerating research, rethinking patient care, and maintaining clinical and operational continuity during this unprecedented time for the global healthcare system.
Watch our presentation on-demand: "Unifying R&D Data in the Cloud: Making biopharma R&D data truly accessible and actionable."
We discussed the Digital Lab landscape and how fragmented data and silos hinder organizations in life sciences from gaining actionable insights quickly and efficiently. TetraScience CTO, Punya Biswal, and Vice President of Marketing, Rachel Daricek also spoke on how we partner with AWS to leverage AWS's best-in-class technologies and featured our case study with Biogen which highlighted the platform in action.
Check out the full event on-demand, including keynote and break-out sessions.
Watch our presentation on-demand from the AWS Healthcare & Life Sciences Web Day Virtual Industry Event.
COVID-19 is shining a light on many laboratory operations processes, making organizations prioritize the implementation of new safety measures to ensure the health and safety of their employees. Pre-COVID-19, users could safely share the same areas and laboratory scheduling did, and still does, rely on manual methods such as calendar printouts, paper sign-up sheets, and whiteboards. While these methods are quick and inexpensive to determine available instrumentation and schedule equipment, they are inflexible, tedious, and inefficient. Oftentimes employees stop using them and they cause a lot of wasted time and resources. Post-COVID-19, lab managers and scientists are facing a new and significant type of problem - working and utilizing instruments that are located in close proximity or in the same room to each other.
With organizations enacting social distancing measures in their laboratories, lab managers and scientists need to be able to know, in real-time, if and when their colleagues are using a particular instrument in the same room they also need to access. Additionally, allowing teams the ability to schedule their workdays around instrument reservations while still adhering to social distancing guidelines will help maximize operational efficiencies while limiting potential health risks.
Organizations and employees need processes that are intuitive, easy-to-use, and reflect real-time data and cannot run the risk of miscommunication or failure when it comes to employees scheduling instruments.
TetraScience Scheduling is a purpose-built solution that allows laboratories to schedule not only instrumentation and equipment, but also assign specific devices to users, and the tasks that need to be run on them. TetraScience Scheduling enables full visibility into resource availability, reservations, and maintenance ensuring the safety of your employees while maximizing outputs.
We’ve designed TetraScience Scheduling with the idea that planning out your experiments and lab resources should be the easy part. Here are some of the top features that we hope will improve both your daily workflow as well as provide key insights into your resources, especially now when it matters most.
Dynamic calendar
See what’s happening in your lab at a glance with our dynamic calendar view. TetraScience Scheduling displays real-time availability of your equipment as well as the metadata associated with reservations and instruments.
Instrument metadata
As with the Tetra Lab Monitoring application, all instrument metadata is easily searchable. You can quickly find your preferred instruments by name, instrument type, location, and more.
One-click reservations
Create reservations or block out time for repairs and preventative maintenance with a single click. Drag your cursor for your desired time window, or simply type it in for fine-tuning.
You can also mark a broken instrument as out of service. This immediately changes the status of the instrument for everyone in your organization to see, preventing additional bottlenecks for your fellow lab mates.
Operational reporting
Dive into your scheduling data to surface the operational insights most important to you. Track project progress and understand which instruments are out-of-service the most. Using the Logbook, you can export CSVs containing reservation metadata to create flexible reports using Excel or the reporting tool of your choice.
TetraScience Scheduling is a purpose-built solution that allows laboratories to schedule not only instrumentation and equipment, but also the people who use those devices, and the tasks that need to be run on them.
Authors:
Yi Jin - Solution Architect
Spin Wang - CEO and Co-Founder
High-throughput screening (HTS) methods are used extensively in the pharmaceutical industry, leveraging robotics and automation to quickly test the biological or biochemical activity of a large number of chemical and/or biological compounds. The primary goal of HTS is to identify high-quality 'hits' that are active at a fairly low concentration and that have a novel structure. Hits generated during the HTS can then be used as the starting point for following ‘hit to lead’ drug discovery effort.
Automation has played a huge role in the development of HTS to date. Tools like the automatic liquid handler and robotic, high-throughput plate readers significantly improve compound screening efficiency and consistency. Robotic automation has transformed the physical aspect of the process. However, experiment data sets remain isolated from one another, requiring manual data acquisition and handling for data storage and analysis. Experiments are automated, but data flow is not.
In order to truly reap the benefits of HTS, biopharma companies need to automate the accompanying data flow. They also need to connect the data with the rest of the Digital Lab to make it accessible and actionable. Otherwise, the vast volumes of generated data will be stuck in yet another silo.
This blog post identifies opportunities for improvement in an example HTS data workflow, based on our experience with biopharma customers, and offers our approach to evolving the HTS data flow to be as efficient and consistent as the physical process.
The following diagram illustrates an example biopharma customer's HTS assay workflow for small molecule compound libraries (edited for confidentiality), leveraging best-in-class instruments and tools in the market.
Diagram 1: Example High-Throughput Screening Workflow
Let's break down this example HTS data flow in R&D labs today, based on our experience working with top pharma and biotech companies:
Step 1: Scientists register the compounds in a compound registry, like Dotmatics Register, generating the experiment ID and compound ID. Scientists also enter compound information, such as molecular weight and initial amount, into an ELN like Dotmatics Studies.
Step 2: Scientists create child samples by sample dissolution or aliquoting. Each child sample is identified by a unique barcode in the sample inventory software like Titian Mosaic. The sample inventory system contains extensive information such as parent sample ID, batch ID, amount, solvent type, sample volume, location in the freezer, etc.
Step 3A: After compound registration and child sample preparation, scientists enter the compounds’ information into the liquid handler software to set up the assay plate in the liquid handler workstation, like Tecan. The sample plate output file information is saved locally to the lab Windows computer.
Step 3B: The HTS assay is incubated based on assay design protocol and detected on a plate reader, like Perkin Elmer Envision. The assay result is also saved locally to the lab Windows computer.
Step 4: After the experiment finishes, the scientist manually moves the files back to the office to analyze the assay data with GraphPad to give either IC50 or target binding information.
Step 5: The analysis result is manually updated in the ELN, like Dotmatics Studies, to complete the experiment.
The key takeaway here is that while the robots are automating the physical component of the experiment, there are multiple instruments and software systems involved in the process and data needs to flow seamlessly into and out of all of them. Today, this is not the case. The Dotmatics components may integrate together since they are part of the same product portfolio. The others may have some point-to-point integrations that you can set up, or APIs that you can use to write your own integrations, but this is real work, needs to be maintained, and ultimately is not scalable. We need an easy way to connect all of these instruments and software systems to a common network to knock down the data silos and get the data flowing, both within this work process and across the broader R&D data ecosystem.
The TetraScience Platform is that common network. Connecting the instruments and software systems needed to conduct HTS transforms the manual steps of data entry, processing, and transfer into an automated solution, saving time, reducing errors, and increasing throughput. It also harmonizes and transforms the data, preparing it for data science, AI, and other advanced analytics - we'll get to this at the end.
Let's take a look at how it works.
Diagram 2: Automating the High-Throughput Screening Data Workflow
Steps 1 and 2: Scientists register the compounds in the compound registry, as before. Except now, the TetraScience Dotmatics connector automatically detects new or modified compounds in the Dotmatics Register and triggers a pipeline to automatically push the information to the inventory management software. As part of this process, the data is also now available to query via RESTful API in the TetraScience Data Lake.
Steps 3A, 3B, 4, and 5: After setting up the assay plates with the liquid handler, scientists run the assay and read the assay readout with various types of plate readers. The liquid handler output file contains sample plate information, including the sample concentration of each well. The plate reader file contains the assay readout. The TetraScience File connector automatically detects the files produced by Tecan and the Envision plate reader, moves the raw instrument files into the Data Lake and then triggers pipelines to parse, merge, and push to Dotmatics Studies. IC50 is then automatically calculated.
Image: Automatically generated IC50 calculation results
In this optimized workflow, only one manual data workflow step remains - initiating the experiment by registering the compound. Scientists also have to physically set up the experiment, but once the experiment is complete, all the data automatically appears in the ELN, with the calculation results shown above completed, as well as in the Data Lake, ready for further querying and analysis.
The TetraScience Data Integration Platform automates the HTS data workflow, providing greater efficiency by removing painful manual data handling and processing from scientists' daily work and by improving data integrity.
Let's compare the two processes side-by-side:
Now that the data workflow accompanying the high-throughput screening process is automated, what's next? Compound information, sample information, type of assays performed, and screening results are now centralized and harmonized in the TetraScience Platform. This seems like a prime opportunity to apply some data science! Check out a related blog post about our Intermediate Data Schema (IDS) to learn more about how we harmonize disparate data, knocking down the data silos. IDS is the open standards method we use to seamlessly move data between and across all the different HTS instruments and software systems, unifying the unique data structure and format from each.
A benefit of the centralized, harmonized data is that it is also prepared for use with various data science and data analytics tools such as Spotfire, Tableau, or Dotmatics Vortex. Our open standards approach means that scientists and data scientists can use the software, platforms, and languages they already know and use - no need to install or learn something new.
Diagram 3: Applying Data Science to High-Throughput Screening Data
You can now fully utilize your HTS data, including querying and visualization of data sets, using your existing data science and analytics tools. For example, scientists can easily query and visualize all active compounds at a certain threshold level in a particular screen, or the behavior of all compounds of similar structure across different screens. Scientists can derive insights that develop more efficient HTS assays, design more active compound libraries, and significantly speed up the drug discovery process.
Watch this video to see the optimized data flow in action, enabled by the TetraScience Platform.
Despite robotic automation, experiment data sets are still isolated from one another, requiring manual data acquisition and handling. The Tetra Data Platform brings automation to the data.
The use of Data Science across all industries has been rising in recent years. At the same time, modern laboratories have experienced massive growth in data volumes. In a single pharmaceutical company, there can be hundreds of High Performance Liquid Chromatography (HPLC) instruments used by process development, quality control, downstream bioprocess, manufacturing, and many other stages of drug R&D. It is common to have millions or tens of millions of injections that need to be available for analysis, and thousands of new injections produced daily.
Waters Empower is one of the most widely used chromatography data systems (CDS). CDS controls chromatographic instruments like HPLCs, runs the injections, collects the raw data, and performs analysis on the chromatogram to detect peaks.
As with most R&D instruments and their control software, accessing the data contained within the Waters Empower CDS has traditionally been challenging. Our Data Science Link for Waters Empower makes the CDS data instantly accessible and actionable. Data scientists can now perform analyses and identify insights using their preferred data science tools, without hours of data wrangling.
We have included more information about how the Data Science Link for Waters Empower works at the bottom of this post.
Once your Empower data is in the cloud, harmonized, structured, and connected to your favorite data science tools – a non-trivial effort – what meaningful analyses can your data scientists and analysts perform? After partnering with many of the world’s leading pharmaceutical companies, we have collected several obvious and non-obvious data science use cases that will help you get started. The use cases are logically organized and have overlaps. We will continue to add to this list over time. If you have a use case to add, we want to hear it! Contact information is listed at the bottom of this post.
Data science tools can easily automate trending and cluster analysis of method performance characteristics, (for example, peak tailing factor, resolution, and relative retention time), ensuring continued method performance and providing R&D organizations with a fast and flexible feedback cycle.
Such analysis can be used in experiment design to drive continuous improvements and optimization of the methods.
This is similar to the previous use case but focused primarily on column performance. Plotting the key performance or suitability parameters, such as peak tailing factor, resolution, or symmetry for one set of sample runs at different times will show very clear trending of column degradation.
Such information is crucial when teams try to generate control charts, predict life time of the column, or try to transfer the method to different teams or to CROs/CDMOs.
Use factors such as peak area, retention time, and tailing factor from the System Suitability Test (SST) runs to "predict" failures before they occur. Use this information to define safe operating limits, automate reporting and alerts when instruments/columns are approaching these limits, and build more intelligent control charts.
Image: Peak area mean value vs. time for each column
Image: Peak tailing factor vs. time for each column
HPLC is a major work horse in R&D. Therefore, it is crucial to optimize the usage of these instruments and understand the operational efficiency of the R&D teams via HPLC data. Data science can help you gain operational insights for the following aspects of HPLC instruments:
Image: Instrument usage analysis
A stability study is a common type of analysis. It usually takes a lot of time and manual effort to organize the data, create the right report or analysis, and predict shelf life. However, once your data is accessible and prepared, data science can automate stability analysis and enhance the insights.
Getting a set of tables and charts is useful, however, scientists often need to visually inspect a group of chromatograms to understand the anomalies and subtle changes in the results. Such visual representation can help the brain to easily detect insights, and often triggers more in-depth and quantitative analysis and comparison.
Image: Chromatogram overlay
It is crucial to follow the appropriate quality procedures while working in an R&D environment. Data science can help quality teams assess adherence to established procedures.
For example:
Quality teams can closely monitor any deviation or anomaly from the organization's established process and immediately take actions to remediate and prevent errors from propagating downstream. For example, if the ratio of results without sign-off suddenly increases, that may indicate a change in process, which may be expected or by mistake.
Constantly assessing the quality procedure will rapidly reduce mistakes, increasing trust and synergy across departments.
Metadata integrity is often difficult to assess. Missing and mislabeled information has significant impact on the reporting and usage of R&D data. Data science tools can assess the completeness and consistency of key business-related metadata entered in the Waters Empower CDS. Armed with such an assessment, teams can take action to improve metadata quality. After all, in the end, you get what you measure/track.
So, what does "metadata quality" mean? Here are some examples:
With access to the metadata, in a consumable format, data science tools can automatically flag experiments without the proper sample naming convention, method naming convention, or instances missing specific custom fields (for example, ColumnId or ELN_Experiment_ID).
Identifying these metadata quality issues and providing feedback in real time will vastly improve metadata integrity, making your R&D data much more actionable.
To improve “metadata quality”, here are the 3 steps you can follow.
Note: this applies to any other type of instruments or workflow.
Using tools like Spotfire, PowerBI you can flag the injections with the incorrect naming. Such as, a dashboard can be updated automatically on a daily basis, thus providing a real time view of the “quality” of crucial metadata.
For the injections run last month, what is the percentage of incorrect / missing metadata? Is this percentage decreasing over time or increasing over time.
If you have some well defined business rules on the structure TetraScience can automatically trigger data pipelines to notify the scientists by sending an email to an email-distribution list. The content of the email can be something like the following
Tuesday 2020 Feb 20, 10:10:10AM CET
Pipeline “Waters Empower metadata verification”
Pipeline failed due to
The R&D data locked inside the Waters Empower CDS silo has tremendous potential, if only you could access it via the cloud and use your data science tools to identify insights and take action! The use cases listed above will drive value and improve efficiency for your teams.
Read on for details about how our Data Science Link for Waters Empower enables these analyses. We can also collect and aggregate important information from other instruments, ELN, or LIMS, together with your Empower CDS data, using the TetraScience Platform.
And let us know if you have a use case to add to the list!
The Data Science Link is an end-to-end application of the TetraScience Platform that automates data acquisition from the most complex (and frequently used) R&D lab instruments, harmonizes it, and moves it to popular data science tools where it can be analyzed.
Image: Data Science Link for Waters Empower schematic
Waters Empower CDS is one of the most complex and frequently used instruments in biopharma R&D. TetraScience’s Empower Data Agent is the world's fastest and most sophisticated product for data extraction from the Waters Empower CDS. It supports advanced features such as:
Install the Empower Data Agent on the order of minutes and point it to the TetraScience Platform. Empower data will immediately flow to the cloud where it will be harmonized and made available to your data science tools within a few minutes.
Once the Data Science Link has extracted, harmonized, and prepared your Empower data, easily connect the following data science and analytics tools to access the data:
These are the tools used most frequently by our current customers; we regularly add new connections. We also support customers in developing and configuring your own applications, written in any programming language you choose.
Share another data science use case or inquire about the Data Science Link application by contacting us at solution@tetrascience.com or any of the channels below.
.png)
Once your Empower data is in the cloud - harmonized, structured, and connected to your data science tools - what meaningful analyses can your data scientists perform? We've collected several obvious and non-obvious data science use cases from our network.
Advanced Data Engineering Improves Data Integrity Using an Allotrope-Compatible, Data Science Ready File Format
Authors:
Evan Anderson - Delivery Engineer, TetraScience
George Van Den Driessche – Scientist I, Biogen
Spin Wang - CEO & Co-Founder, TetraScience
The pharmaceutical industry generates experimental data every day that is stored on local PCs or on instrument vendor servers, with vendor dependent data schemas. These practices result in the creation of data silos across pharma that do not adhere to FAIR (Findable, Accessible, Interoperable, and Reusable) data principles and prevent companies from utilizing all the information found in their raw data sets.
“The lab of the future is built on data. Right now, our cell counter data is largely inaccessible, and the heterogeneous nature of the information makes it difficult to analyze without significant manual manipulation. My team needs to make this data accessible and actionable for our scientists and data scientists,” says Len Blackwell, Associate Director of Strategic Analytics at Biogen.
This blog post highlights how our recent collaboration with Biogen knocks down the data silos associated with their Beckman Coulter Vi-CELL cell counter results, making the data readily available for further analysis using standard data science tools.
Cell counters enable process development scientists to differentiate the number of viable versus non-viable cells using the trypan blue exclusion cell counting method. These values are then used to measure overall cell density and cell viability percentage. Cell density measurements help monitor cell culture feed requirements and the cell viability percentage assesses the overall health of a cell culture.
“Cell counting is a critical step in the biomanufacturing process that provides information about the density and viability of the mammalian cells that produce our protein products. In the process development laboratories, daily cell counts inform process development engineers of the results of experimental conditions with the goal of optimizing cell health and productivity,” says Brandon Moore, Cell Culture Engineer at Biogen.
A cell culture study typically lasts 14 days, with one sample analyzed from each condition per day. Biogen’s cell counter sample analysis produces 50 images that are analyzed with the trypan blue exclusion cell counting method. The resulting measurements are stored in a single text file as aggregated values and raw data arrays. The image files, used for the measurements, are exported and stored separately from the numerical data.
This presents a few challenges:
Image: The Beckman Coulter Vi-CELL exports images and a .txt report for each experiment.
TetraScience addresses these data integrity challenges with the Tetra Data Platform. The platform provides automated cell counter file movement from the instrument PC to an AWS data lake. Once the files are moved to the data lake, they undergo two conversion pipelines. First, the instrument data schema is mapped into an Intermediate Data Schema JSON file (IDS-JSON) and then the IDS-JSON is mapped into a pharmaceutical standard Allotrope Data Format (ADF) file. The ADF file provides a single output that captures both image files and the numerical data reports generated per cell counter sample.
Image: an excerpt of the cell counter report as a JSON in the IDS format.
Once the cell counter data is moved to an AWS data lake and packaged as either an IDS-JSON, or ADF, data scientists can begin analyzing these files with python notebooks like Google CoLab, or other common data science tools. Scientists can call files related to cell growth studies by querying the IDS-JSON files with ElasticSearch. Next, the cell density data is plotted versus date using the Pandas and Seaborn python libraries. ADF files enhance cell counter data integrity by combining numerical and image data into one file output; scientists can access this information with the H5py python library. The combined data outputs enable new types of data analysis, such as cell contamination monitoring with cell image analysis. For more information on the ADF file format, check out our blog post about the ADF graph model and leaf node model.
Image: Converting cell counter data into an ADF wraps up the standardized data along with associated images and ontology specified by the Allotrope Foundation
We can also easily use TetraScience REST API to import data into interactive python notebooks to do more detailed image analysis.
Image: Use TetraScience REST API to access your data using popular data science tools, like Jupyter iPython notebooks
“There are two really important improvements that come out of this process for Biogen. First, analysis is fully automated; once someone reads a sample in the cell counter, the data for the growth curve is visualized in the BI tool. This was previously a manual process with a lot of data movement. Second, data integrity is improved by aggregating multiple files from each sample into a single file and automating storage of the data. These are key points and should not be overlooked, “ says Blackwell.
We are delighted to have the opportunity to work with innovators at Biogen like Len Blackwell, Associate Director, and George Van Den Driessche, Scientist I. This collaboration will save their scientists time, make their cell counter data truly accessible and actionable, and negate the risk presented by separately storing files.
Use case illustrating how experimental data from a cell counter is automatically collected, centralized in a data lake, and converted into an ADF-compatible format, saving time, reducing error, and making the data accessible and actionable.
About LRIG and the event:
LRIG New England is a rapidly growing special interest group focused on laboratory automation. Membership consists of scientists and engineers, primarily from the pharmaceutical and biotechnology industry, with chapters across the US and in Europe. The LRIG mission is to provide and facilitate instruction for both self-development and the benefit of the laboratory automation community.
The LRIG-New England's first virtual Rapid Fire event brought new ideas and technologies to members in a quick and concise format. There were be 3 speakers, each presenting for a total of 15 minutes. Topics focused on new technologies for the lab: Data Engineering, Alpha CETSA assays, and IoT in the lab.
TetraScience CEO and Co-Founder, Spin Wang, discussed "Data as 'Plumbing' of the Digital Lab: Evolving to a Sophisticated System with Data Engineering."
TetraScience CEO and Co-Founder, Spin Wang, presented during the May 26 LRIG-New England lunchtime virtual Rapid Fire event.
We believe one of the critical components of the Digital Lab is the flow of data. Without the flow of information, data is siloed and fragmented, and it is nearly impossible to take action based on the information. To enable scalable data flow, the Digital Lab needs an Intermediate Data Schema (IDS).
The IDS is used to decouple the data sources (producers) and data targets (consumers). This decoupling significantly reduces the total cost of ownership for exchanging data in a heterogeneous R&D lab environment. It also enables data science, visualization, and analytics.
IDS is also a stepping stone towards the Allotrope Data Format (ADF). We do not recommend directly converting RAW lab data into ADF, since ADF is still an evolving standard. We need something "intermediate" as the bridge to use what we have now, while future-proofing to easily adapt to the rapid changes.
Rae Wu - Life Sciences Data Analyst
Yi Jin - Solution Architect
Evan Anderson - Solution Architect
Kai Wang - Delivery Lead and Sr. Software Engineer
Spin Wang - Co-Founder and CEO
Stay tuned for the second blog of this blogpost series. We will cover our experience and suggestions in how to avoid losing data while transforming in and out of IDS, how to manage, govern IDS and leverage ontologies, and how to create IDS for your own data sets and business logic.
Data Sources
The life sciences R&D lab is full of heterogeneous data sets and diverse interfaces for data acquisition. Instruments and CRO/CDMOs produce a large amount of experimental data.
Fundamentally, these "source" systems are designed to run a task, execute a job, and/or deliver services. Providing the data in an accessible format and interface is not the data sources’ main consideration.
Many instrument manufacturers make their data format proprietary as a barrier against competition, incentivizing users to continue purchasing their software and hardware.
Data Targets
There is a similar heterogeneous landscape on data target side.
The heterogeneity is a key nature of the scientific R&D process, which requires data and information to be handled based on its particular domain and context. Since data is consumed with very specific context, many data targets (e.g., ELN, LIMS) require data to be provided in its specific format or using its provider's APIs.
In such a many-to-many data landscape, it is essential to use an Intermediate Data Schema (IDS) to harmonize heterogeneous data and decouple data sources from data targets.
As the following diagram shows, if each data source and data target is left to communicate with each other, N X M number of point-to-point connections or data flow / translations are needed. However, if data from the data sources is harmonized into an intermediate format, the total cost of ownership can be reduced by an order of magnitude to N + M. The IDS approach makes data flow manageable.
From a first principle, such an IDS format should have the following characteristics:
Such a heterogenous data landscape presents an exciting challenge, but not something new. The broader tech community has faced a similar challenge since the Internet and web started to be dominate the world, more than 20 years ago.
"JSON has taken over the world. Today, when any two applications communicate with each other across the internet, odds are they do so using JSON." - The Rise and Rise of JSON
JSON is adopted and supported by Google, Facebook, Twitter, Pinterest, Reddit, Foursquare, LinkedIn, Flickr, etc. Without any exaggeration, it is safe to say that the Internet communicates using JSON.
Here is an example of a JSON file describing a puppy (not just any puppy, her name is Ponyo and you can follow her on Instagram).
Without any prior training, just about anyone can easily understand and read the basic information about this puppy, in this format.
Here at TetraScience, we made the decision to use the most popular data interchange format of the Internet as our Intermediate Data Schema (IDS) for the Digital Lab, building our Intermediate Data Schema (IDS) on top of JSON Schema.
Here are some additional examples:
Image: Example IDS JSON describing an injection
Image: Example IDS JSON describing a gradient table in liquid chromatography
Image: Example IDS JSON describing a cell counter measurement
Inside the IDS, you can capture as much information as possible.
From the top level, this includes:
JSON seems great for hierachical key value pairs, but what about a numerical matrix? These are pretty common in the labs. In this case, we use a data cube. If you are familiar with Allotrope or HDF5, you can see that this is inspired by the concept of data cubes in ADF and data sets in HDF5.
{
"datacubes":[{
"name": "Plate Reads",
"description": "More information (Optional)",
"mode": "absorbance",
"another property": "you decide",
"measures": [{
"name": "OD_600",
"unit": "ArbitraryUnit",
"value": [
[1.19, 1.05, 1.05],
[1.11, 0.90, 0.95],
[1.11, 0.93, 0.95]
]
}],
"dimensions": [{
"name": "row",
"unit": "count",
"scale": [1, 2, 3]
}, {
"name": "column",
"unit": "count",
"scale": [1, 2, 3]
}]
}]
}
You can use data cubes to model many types of experimental data sets, such as:
INSTRUMENTMEASUREDIMENSIONChromatogram1: detector intensity1: wavelength
2: retention timeRaman Spectroscopy1: intensity1: wavenumber shiftPlate Reader1: absorbance
2: concentration1: row position
2: column positionMass Spectrometer1: intensity1: mass charge ratio
2: time
We do not recommend creating JSON files larger than 100MB. Instead, consider using File Pointers.
JSON is not suitable for storing large data sets. We do not have to force everything into JSON either. Leveraging the cloud and other purpose-built, efficient, and analytics-ready file formats, like Apache Parquet and HDF5, you can easily reference large binary files from an IDS.
{
"result": {
"cell": {
"viability": {
"value": 0.2,
"unit": "Percent"
}
}
},
"image": {
"type": "s3file",
"fileKey": "uuid/RAW/folder/batch1_day2.parquet",
"bucket": "ts-dev-datalake",
"version": "3/L4kqtJl...",
"fileID": "9ff46a4e-c6a0-4cfe-b6ff-1e7b20bbf561"
}
}
Life sciences organizations commmonly pick from the following 3 formats, depending upon the use case.
Use Cases by format:
Hopefully now you have a basic understanding of JSON, its popularity in the broader technology ecosystem, and its ability to capture scientific data.
Let's now take a look at its compatibility with some of the best informatics software in the Digital Lab space.
JSON is used to send data into some of the best informatics software, like Dotmatics, Riffyn, Benchling, Scilligence, IDBS, and many others.
Let's turn our attention to some trends in data science:
All of these tools have seamless native support for JSON.
Another benefit of JSON is that it's interchangeable with tabular formats (those with rows and columns). At first glance, IDS JSON does not look very tabular, but it is actually quite easy to transform JSON into a tabular structure.
Image: Use Pandas to "flatten" or "normalize" the JSON. There are also countless other tools to do this.
As a result, some of the best visualization and analytics tools that rely on tabular data and SQL interface - Dotmatics Vortex, Tibco Spotfire, Tableau - can leverage IDS JSON with very minimum overhead, one of the important criteria of an Intermediate Data Schema
Image: Example visualization using Dotmatics Vortex
This is good question. There have been a lot of conversations about converting all experimental data into ADF files and using Semantic Web RDF graphs. Naturally, we asked the question, "Is ADF a good option as the intermediate data schema/format?"
Let's think about it.
Allotrope Data Format is really HDF5 + Semantic Web RDF. Let's discuss these two separately.
HDF5 is a popular binary data format for storing multi-dimensional numerical arrays along with heterogeneous data in one single portable container. In fact, it is one of the recommended file formats in the section above when it comes to saving large numerical data sets and binary files in the IDS JSON. See File Pointers. As a result, HDF5 is already part of the IDS JSON.
The image below is an RDF representation of a LCUV injection. This only captures one part of the information (10-20% of the experimental information from the run) and, as you can see, it is already getting quite complicated.
Image: RDF representation of 10-20% of the data from an LCUV injection
If we apply the criteria of an Intermediate Data Schema (IDS) to RDF, here are our observations:
WHY RDF IS NOT SUITABLE
As a result, we do not believe RDF is suitable as the Intermediate Data Schema for R&D labs. Major barriers include the learning curve and the lack of tooling.
These are all the reasons we chose JSON as our Intermediate Data Schema (IDS) for the Digital Lab, and we think you should too.
Pick something that is popular, battled tested, easy to read/write, and supported by a vibrant tech community as well as almost all the websites on the Internet.
Pick something that is inclusive and transferrable to other formats when use cases justify further transformation. That's why it's called Intermediate Data Schema :)
Note: the list above is inclusive but not exhaustive.
Here is a video illustrating how easy it is to learn and use JSON.
Here is a roundup of curated articles about Semantic Web and RDF for further reading.
We believe one of the key building blocks of a Digital Lab is the flow of Data. Without the flow of information, data is siloed, fragmented, and nearly impossible to drive action. To enable scalable data flow, Digital Lab needs an Intermediate Data Schema...
Back in my college days, I worked on (or near) the Haystack project — an attempt to build a UI for the semantic web. It was built on top of the Eclipse IDE, and focused on personal information management and bioinformatics as its two domains. Each semantic data type (think IRI) was mapped to a program written in a custom language called Adenine, that rendered a UI specific to that type. Adenine’s syntax was itself a subset of RDF, so you could write it in N3. It was a cool vision, but never came to fruition.
Ever since then, semantic web (or SemWeb) is something I've thought about a lot. This is very relevant to my role as CTO at TetraScience because our platform is dedicated to collecting, centralizing, harmonizing, and preparing R&D lab data for exploration and analysis with techniques like machine learning and data science. Ontologies, metadata, and formatting are all critical to making data accessible and actionable (aka useful). While we each have our own individual opinions about the future and practicality of the semantic web, our goal as a company, and my responsibility as the CTO, is to ensure we achieve the end goal of accessible/actionable data, using the best means possible.
Here is a collection of thought leadership articles about semantic web that I'm tracking. This is a question we are asked often, so I thought I'd share.
I'll add to this list as new, interesting articles are published. What are your thoughts about semantic web? Are you using or building it? Contact us via one of the methods below to discuss further.
Here is a collection of thought leadership articles about semantic web that we are tracking. This is a question we are asked often, so we thought we'd share.
This week, we are very excited to launch the first cloud-native, data science ready ADF Converter. Our application converts your heterogeneous experimental data sets into ADF files, leveraging Leaf Node pattern, Allotrope Foundation Ontology and QUDT for ontology, HDF5 for underlying format. We would like to share how we get started and how we gained clarity and conviction to officially support ADF in our journey.
We believe that storing your heterogeneous experimental data sets in one single HDF5 file, embedding ontological labels on key data fields, and doing that in a way that can be consumed by any data science and 3rd party software, and can be extended to full semantic graph, is indeed a promising data management strategy for organizations to consider.
Authors: Evan Anderson - Delivery Engineer, Vincent Chan - Product Owner/Software Engineer, and Spin Wang - CEO & Co-Founder
TetraScience joined the Allotrope Foundation in 2017 as a member of the Allotrope Partner Network. For the last 2.5 years, we have worked actively with the foundation and its working groups, many pharmaceutical companies, and instrument manufacturers to pursue the vision of experimental data standardization for the Digital Lab. We are deeply impressed and motivated by the community built by and around the Allotrope Foundation, and by their deep belief in data standardization to reduce error and enable analytics and data science.
However, truth be told, for the team at TetraScience, it was not a smooth journey; we struggled and frequently questioned our choices.
In the beginning, when the challenge was mainly about learning various concepts involved in Allotrope, the community provided a lot of assistance and helped us to become more knowledgeable. Our team must have read the ADF Primer more than 10 times. After being able to convert one file, we then struggled to convert other data types scalably and repeatedly; then we struggled to make sure the file could be consumed easily and to get the information out.
Because of our conviction in the vision, and also the unwavering enthusiasm we saw from the community members, these challenges did not really bother us. Instead, these became exciting problems that our engineering and product team discussed on a daily basis. We treated these as opportunities to contribute and received tremendous help from the Foundation and the community.
We published our internal training document: Allotrope 101, and contributed automation and libraries we built to the Foundation. We provided at least two presentations in each of the past five Allotrope Connect workshops to report our findings and progress. As we contributed, we also voiced our concerns and questions:
As a start-up with high opportunity cost and limited resources, this is a major decision. We can not support Allotrope without having conviction that it has a differentiated value proposition and without genuinely feeling confident. We relentlessly asked ourselves - what are the use cases, why do those use cases have to be achieved by ADF and not the alternatives, and by the way, what are the alternatives?
That’s why, in the last 2.5 years, despite our active participation, we have always been hesitant on what we should do. Our strategy is not to follow and adopt blindly. Instead, we question why the use cases have to be achieved by ADF, and what are ADF’s unique advantages?
With the help of the Foundation, our customers, and through many debates and iterations, we started to gain more clarity around ADF’s unique value proposition.
ADF, as a file format, is really HDF5 + semantic web RDF graphs. These solve very different use cases and have specific, unique benefits.
On the HDF5 side
On the semantic web RDF side
It’s also important that we realize ADF is not suitable for all use cases; it is not a magic bullet that will solve all the issues.
Instead of discouraging us, understanding the limitations provided us with much more clarity on how to recommend ADF to our customers and thus gave us conviction on where ADF is uniquely positioned to excel!
We believe that storing your heterogeneous experimental data sets in one single HDF5 file, embedding ontological labels on key data fields, and doing that in a way that can be consumed by any data science and 3rd party software, and can be extended to full semantic graph, is indeed a promising data management strategy for organizations to consider.
During this process, we continue to be encouraged by the community’s enthusiasm -- people from different pharmaceutical companies and manufacturers working together collaboratively, iterating towards a common vision, willing to learn from past experience, and finding the right balance between vision and execution. A lot of these ideas and opinions were inspired by others in the community. We could not be more grateful for the inspirations we received from the community!
This week (early April of 2020), we are very excited to launch the first cloud-native, data science ready ADF Converter. It is an application built on the Tetra Data Platform that converts your experimental data into ADF files, leveraging Leaf Node pattern, Allotrope Foundation Ontology (AFO) and QUDT for Ontology, and HDF5 for underlying file format. It supports all the instrument types modeled thus far by the Allotrope Modeling Working Group using Leaf Node pattern, and is expected to support up to 40 instrument models by the end of 2020. You can leverage these models to document and analyze key experimental data in ELNs, LIMS, visualization, data science tools, or any software you write yourselves.
Here are our core convictions that shaped the ADF Converter.
First, we believe that the barrier to data access needs to be as low as possible. The data format serves the need of use cases and is a means to the end.
Right now, the only way to read an ADF file is via the Java/C# library provided by the Allotrope Foundation. This limits the ability for Electronic Lab Notebooks, Data Science tools (Python, R), and Business Intelligence & Analytics tools (Dotmatics Vortex, Tibco Spotfire, Tableau) to use the ADF files.
To address this limitation, we made sure that ADF files can now also be opened using Python, R, and easily consumed by Data Scientists, and made them compatible with HDF group’s Kita and HSDS. Now, leveraging any tools or programming language compatible with HDF5, using R Data Functions in Spotfire, you can easily extract the information from ADF into your data science related applications.
Image: use Python to explore and visualize your ADF file
Second, we believe that programmatic API and automation are crucial for data standardization. Standardization is only meaningful when the number of files following that standard exceeds a critical amount. To reach that critical mass, automation is necessary. As a result, the ADF Converter has a flexible programmatic interface for you to ingest input files, monitor conversion progress, and search and retrieve converted ADF files. Third party applications can now leverage this API for conversion.
Image: ADF Converter ingesting files + third party application retrieving the files
Third, we believe in starting with simple patterns, because simplification allows automation, automation leads to scale, scale leads to adoption and momentum, which provides more user requirements and use cases. These requirements and use cases can help to solidify the next iteration. The Agile development philosophy also applies to data modeling. The ADF Converter starts with the Leaf Node pattern and will include the aggregation pattern after the working groups finish the design.
Image: Allotrope Leaf Node pattern
It has been a great journey. We encourage more people and organizations to be involved and participate actively. It’s a collaborative community that will result in value and deep relationships! We hope our effort will enable organizations to overcome the barrier of initial adoption and start to truly evaluate and explore ADF in real production settings against your use cases. By doing this, a data format like this one can be truly battle-tested and demonstrate its vitality. There are still many unknowns, and we look forward to further collaborating on this journey of Data Standardization for Digital Labs!
Read more about the ADF Converter and our approach, or contact us with questions, comments, or feedback.
Our goal is to enable other organizations to overcome the barrier of initial adoption in order to evaluate and explore ADF in real production settings against your use cases. By doing this, such a data format can be truly battle-tested and demonstrate its vitality.
Using the Leaf Node model, scientists, software engineers, and data scientists can rapidly iterate on the data model, create and query standardized data sets, while semantic experts focus on the ontology and semantics. It’s a division of labor, allowing common activities to be easy & fast, while maintain compatible with semantic world.
An added benefit of the Leaf Node model is that it can be easily transformed to / from popular formats such as JSON, Tabular formats like CSV and Columnar formats Parquet. These formats make the data easily compatible with common software engineering, data sciences and visualization tools. Being interchangeable with popular software and data science ready formats is another major advantage of the Leaf Node model.
Written by: Spin Wang
Earlier this year, we discussed the basic concepts of Allotrope Data Format (ADF) in this blog post: Allotrope 101. One of the keys of Allotrope is its Data Description, a triple store leveraging the semantic web and Resource Description Framework (RDF) graphs.
Traditionally Allotrope data description is presented by what we call a “Full Graph” stored in RDF, something that looks like the following --
The goal of the full graph is very exciting, it captures the relationship of the entities. For example
Such relationships can potentially allow the machine (computer software) to understand what is a sample, a chromatography injection, and autosampler and how they are related to each other in an abstract way, like a lab scientist. However, the downside is that it introduces a LOT of ontological, taxonomy and even philosophical complexity & overhead. In preparation for the machine to understand the data in the future, scientists now incur more overhead and get stuck.
Quickly the community realizes that it is non-trivial to build and use a Full Graph data model, for the following reasons
In light of this observation, the community proposed the concept of Leaf Node model, which is the theme of this blogpost.
Essentially, the Leaf Node model says -- “What if we only focus on the Leaves of the Full Graph, namely those nodes that are directly associated with the data?”.
This allows the scientists, software developers, and data scientists to quickly zoom into what is the important part of the graph, the actual data fields, and their values. Example Leaf Nodes are listed below. They look like
When represented in RDF and saved in ADF, Leaf Node is composed of the following triples.
Leaf Node model is essentially whole bunch of Leaf Nodes. Leaf Node model also supports an array of Leaf Nodes which are related to each other, such as an array of chromatogram peaks. We will leave this to future articles to explain in more detail.
You will probably ask: how about the semantic meaning and relationship? How is the information such as “sample is input to an experiment” captured and how can we tell the machine to understand what is a “sample”?
The answer to this actually quite delightful, since an IRI is attached to node (for example, result#AFR_0001111 is attached to cell viability), and because that IRI is already part of an ontology, then the relationship between the nodes have already been rigorously and elegantly defined in the ontology. That IRI serves as a semantic hook or label, that explains what is “viability” and bridges the Leaf Node graph with the ontology. If you were to want a “Full Graph”, simply combine the Leaf Node graph with the ontology.
With this approach, lab scientists, software engineers, and data scientists can rapidly iterate on the data model, easily create standardized data sets, easily query the data sets. While the knowledge engineers and semantic experts can focus on the development of the ontology, which is the right place to describe what is a sample and it can be part of an experiment.
Leaf Node approach is essentially a division of labor, allowing what should be easy & fast to be actually easy & fast, while enabling compatibility with the semantic world via the IRI. The delineation of data (captured in leaf node) and semantics (captured in the ontology) enables scientists, software engineers and data scientists to easily create, validate and read the data, while sementic experts can focus on the ontology.
An added benefit of the Leaf Node model is that it can be easily transformed to / from popular formats such as JSON, Tabular formats like CSV and Columnar formats Parquet. These formats make the data easily compatible with common software engineering, data sciences and visualization tools. Being interchangeable with popular software and data science ready formats is another major advantage of the Leaf Node model.
{
"experiment": {
"name": "my test"
},
"sample": {
"id": "123"
},
"injection": {
"volume": {
"value": 1,
"unit": "Microliter"
}
}
}
EXPERIMENT_NAMESAMPLE_IDINJECTION_VOLUME_VALUEINJECTION_VOLUME_UNITmy test1231Microliter
To find out more about how you can use Allotrope Leaf Node Model and automatically standardize your lab data for analytics, automation and archiving, please reach out to us at www.tetrascience.com/contact-us!
Specialization and compatibility are possible with the Leaf Node - scientists, engineers, and data scientists can rapidly iterate on the data model to create and query standardized data sets so ontology experts can focus on semantics.
Blog post below infographic
Now you just need to set up your alert set points, and then you won’t need to think about it anymore.
But how do you do that? What happens if you don’t choose the right alert set point? How do you know you chose correctly?
If you’ve never done this before, it can be hard to know what to do here - under-sensitive alerts might mean you’ll miss a problem with your equipment, but over-sensitive alerts are annoying and will cause alert fatigue.
Alert fatigue happens when you receive so many alerts that you learn to ignore them. If you receive 99 alerts that are false alarms due to normal usage, it is pretty likely that you will ignore the 100th alert. Of course, that 100th alert is the one that indicates a freezer failure, or something equally important.
At TetraScience, we’ve monitored more than 3,600 pieces of equipment over the last four years. We've collected lots of data about how freezers and incubators perform and what alert settings work for the Lab Managers and Ops/Facilities folks who rely on our Lab Monitoring system. One of the most common requests we receive is for alert setting recommendations. We decided to gather our data and anecdotal experience and write it down - so here it is:
When setting alerts, the variables we have to work with are alert threshold and delay. The way alerting generally works is this - once the temperature (or other data feed) has crossed the set alert threshold, a timer starts. That timer continues for the duration of the set delay, and if the temperature is still out of bounds after that period of time, you receive an alert.
As an example, if you have a -80℃ freezer, where you have set an alert threshold of -65℃ and a delay of 30 minutes, you would receive an alert if the freezer temperature went above -65℃ and remained above -65℃ for 30 minutes. The figure below shows what this looks like on your TetraScience Lab Monitoring dashboard.
The purpose of setting an alert threshold is pretty straightforward: if your equipment exceeds a set temperature, you want to know so you can take corrective action.
When selecting a threshold, the important thing to remember is that temperature naturally fluctuates during normal usage.
For example, a primary cause of temperature fluctuation is users opening and closing the door during the course of a normal day - this will cause excursions that last for a few minutes before your equipment recovers. Freezers will also have a sinusoidal temperature variation even when nobody is using them. This is caused by the compressor cycle and can be a noticeable variation (+/- 5℃ would be very typical).
Because these variations are part of normal operation, we typically recommend thresholds that are a few degrees outside of normal operations. Below are some examples of reasonable thresholds:
Note that we do not recommend low temperature alerts for -20s or -80s: these generally are not useful and can cause alert fatigue. We do, however, sometimes recommend low temperature thresholds for 4℃ refrigerators, as you may have material that you do not want to accidentally freeze. However, risk of hitting freezing temperatures does vary by type of refrigerator. For example, low temperature thresholds can be helpful for refrigerators that are likely to have frost on top.
The purpose of setting a delay might be a little less obvious - wouldn’t you want to know immediately if your equipment is out-of-bounds? In some cases, this is true (if you’re monitoring a gas manifold, and it goes into alarm, there’s no reason for a delay).
But for cold storage and incubators, the time it takes to return to the temperature set point after opening the door can be 20-30 minutes or more - especially if users open and close the door several times in rapid succession.
Because of this, we typically suggest alert delays in this range:
We can use a shorter delay for incubator high temperature alarms because the incubator temperature does not generally rise with normal use. High incubator temperature normally means there is a problem with your HVAC system or the incubator itself.
The best monitoring system is one that you use, not one that you tune out.
Alert setup shouldn’t be difficult, and it shouldn’t take a lot of fine-tuning down the line. Though lab equipment can show some variation in typical operating ranges, we usually find that you should be able to set universal alert thresholds and delays for each type of instrument. The important thing to remember when you are setting up your lab monitoring system is to avoid the extremes of alert sensitivity - the best monitoring system is one that you use, not one that you tune out.
Do you have alert threshold/delay setting best practices to share? Additional questions? Let us know!
.png)
Choose the right alert set points for your freezers and incubators Use this guide to ensure you don't miss anything important while avoiding alert fatigue.
Authors:
Benjamin J. Woolford-Lim, Senior Laboratory Automation Software Engineer, GSK
Vincent Chan, Product Owner & Software Engineer, TetraScience
Spin Wang, Chief Technology Officer and Co-founder, TetraScience
Mike Tarselli, Chief Scientific Officer, TetraScience
How to learn the Allotrope Framework and use the Allotrope Data Format (ADF):
Don’t worry if you get stuck or have questions - try these helpful resources:
Motivation
As life sciences organizations become increasingly data-driven, the strategic importance of high-quality data sets grows. Scientific instruments were not historically designed as “open” systems and typically generate data in proprietary or vendor-specific formats. The resultant data silos greatly reduce the ability to gain insights and perform analytics on scientific data.
The Allotrope Foundation aims to revolutionize the way scientific data is acquired, shared, and how actionable observations from the data are attained by establishing a community and framework for standardization and linked data.
Semantic Web
The Semantic Web, an extension of the World Wide Web, provides a common framework for data sharing and reuse across applications, enterprises, and community boundaries. Its goal is to make Internet data machine-readable and to integrate content, information applications, and systems. With a Web of Information, users can contribute resource knowledge openly and freely, which leads to unprecedented growth. To implement Semantic Web, however, there needs to be a way to allow information interchange.
RDF
Semantic Web promotes common data formats and exchange protocols through a popular modeling language, Resource Description Framework (RDF). It is the basis of languages such as Web Ontology Language (OWL). RDF relies on the concept of "triples”; it extends the linking structure of the Web by using uniform resource identifiers (URIs) to name the relationship between things as well as the two ends of the link.
This simple model allows structured and semi-structured data to be mixed, exposed, and shared across different applications. Note that RDF as a data model is distinct from RDF/XML, a means of representing RDF in XML, largely superseded by easier-to-use formats like Turtle.
Triples
Triples store elements or facts. A set of triples can be combined to represent a graph of data and relationships in an ontology. Triples consist of a subject, a predicate, and an object. For example:
It can either be another resource like the subject, i.e. an instance of an entity or an ontological class, or it may be some fixed literal value such as 500.14 or "Allotrope".
Here is a snippet of the QUDT's that contains some facts about the unit of Atomic Mass, namely u or dalton (Da), expressed in Turtle syntax.
Once you have a graph, it can be queried using SPARQL, a query language similar to SQL but designed specifically for semantic content. Every ADF file can store triples about its data in the Data Description. Allotrope Foundation Ontologies (AFO) provide consistent terms and relationships across instruments, techniques, disciplines, and vendors.
RDF provides a mechanism that allows anyone to make a basic statement about anything and layer those statements into a single graph.
Now imagine an instrument being able to automatically produce those statements and add them into a big pool of scientific data with consistent terms and relationships between the data sets. Scientists and data analysts can now spend the majority of their time analyzing and gaining insights into the data, instead of trying to interpret or interchange it.
Wouldn’t that be pretty powerful?
URI and IRI
Remember URIs, from the RDF section above? URIs can uniquely identify a resource or name something. By leveraging URIs in the RDF framework, one can represent ontologies in a unique and even resolvable way.
International Resource Identifiers (IRIs), unlike URIs, are Unicode character set in addition to ASCII characters (URIs’ limitation).
SPARQL
SPARQL, pronounced "sparkle" and recursively meaning SPARQL Protocol and RDF Query Language, queries database Triples. It’s structurally similar to SQL. To learn more, check out the SPARQL tutorial.
Below is a set of triples in Turtle format. These triples form a graph that describes the cell counter measure as the total cell count at 1972.0.
Here is an example of SPARQL query that obtains the total cell count from the previous graph.
Leveraging triples and SPARQL, you can perform powerful queries on top of highly connected data sets - the key benefit of using Semantic Web.
SHACL
Shape Constraint Language defines and validates constraints on RDF graphs. It is a relatively new standard from the W3C.
Using RDF triples allows fact expression and notation in order to connect to other facts across datasets and domains. Super! However, this same flexibility strength can be a weakness: it can cause inconsistency in data representation. This is where SHACL comes in.
SHACL can validate an RDF graph against a set of constraints or rules. By encoding data models in SHACL, this automatic validation checks conformance of our triples and graphs to the expected model, with all required information in the correct place (and linked in the right way). Now these datasets can be searched via the same SPARQL queries, enabling easy and consistent linking to other datasets with validated data structure.
Here’s an example of a SHACL file snippet:
This snippet (unnamed:checkForEntityNode) tries to make sure that for an entity node in the graph that belongs to class viability (defined as http://purl.allotrope.org/ontologies/result#AFR_0001111 in the Allotrope Foundation Ontology), there is only one numerical value and only one unit. Notice that the SHACL file is also presented as a set of triples in the Turtle format.
Taxonomy
A hierarchical classification of entities, using the same relationship type, e.g. "is a subclass of" throughout. Taxonomies are typically represented by a tree structure (think like the animal kingdom KPCOFGS).
Ontology
A superclass of taxonomies, with several different relationships, e.g. "is a", "has a", "contains a", and with multiple inheritances allowed in the same ontology. Whilst taxonomies can be represented as a tree due to their hierarchical nature, ontologies have more complex relationships and are modeled as graphs.
Graphs and Graph Databases
Graphs are a powerful way to store and explore unstructured and semi-structured data to identify relationships between data and quickly query these relationships.
Data is most often represented in tabular form, e.g. relational databases. What are advantages to modeling data as a graph over the traditional relational data format?
Graph databases have advantages over relational databases for use cases like social networking, recommendation engines, and fraud detection, where the relationships between data are arguably as important as the data itself. If you use traditional relational databases, you would need a large number of tables with multiple foreign keys to store the data, which are difficult to understand and maintain. Furthermore, using SQL to navigate this data would require nested queries and complex joins that quickly become unwieldy, and the queries would not perform well as your data size grows over time.
In graph databases, the relationships are stored as first-order citizens of the data model, as opposed to relational databases which require us to establish relationships using foreign keys. This allows data in nodes to be directly linked, dramatically improving the performance of queries that navigate relationships in the data. It also enables the model to map closely to our physical world.
Additional graph information:
Tools and Technologies
Summary
By establishing a framework and unified data formats to structure the multitude of experimental data generated in life sciences R&D, the scientific community has the ability to focus on pushing the needle of scientific innovation.
.png)
The Allotrope Foundation, an international consortium of pharma, biotech, and other research-intensive industries, has developed advanced data architecture to transform the acquisition, exchange, and management of laboratory data throughout its lifecycle.