Begun in 2024 at our ten-year mark and finished here in 2026, our twelfth.
The past few years in scientific informatics have been productive! Late 2022 through 2023 saw the launch of the consumer-grade AI platforms that we are all using today. Someone hit the nitrous switch on the dashboard and everything has been a blur ever since.
In 2024, Workflow Informatics started a 10-year retrospective series on drug discovery research informatics from our point of view. Two years on, we thought it would be a good time to complete this retrospective. Workflow Informatics opened its doors in December 2013, making 2024 our tenth year in business and 2026, as we finish this, our twelfth. From those beginnings as a boutique Pipeline Pilot consultancy, we have expanded alongside modern drug discovery, scaling into laboratory robotics, cloud data warehouses, DNA-encoded libraries, and AI/ML workflows.
Reflecting on hundreds of customer engagements, we see recurring bottlenecks wherever science meets software. This retrospective examines the evolution of drug discovery informatics. Here we review the following eight topics. By no means do these topics represent an all-encompassing analysis, just a compilation of some of the common themes in roughly chronological sequence.
- Laboratory Operations
- CRO Data Management
- Data Warehouses
- Application Integration
- Automation
- Data Standards
- Cloud Computing & Software
- The Rise of AI
Chapter 1: Laboratory Operations
Initially, Workflow Informatics concentrated on cheminformatics, primarily around medicinal chemistry, QSAR, predictive modeling, and data visualization challenges. We began by working with many start-up drug discovery companies, since few of these companies had dedicated research informatics personnel. This is understandable, as most start-ups begin with heads of Biology and Chemistry and a specific technological approach. Generally, they do not start with a lot of data, typically taking 6-12 months to start laboratory operations.
Once laboratory operations commence and they begin to generate data, the data sets usually end up in spreadsheets and documents. Eventually, these flat files become insufficient and ineffective data storage mechanisms, since they are not sufficiently searchable, there tend to be many versions/copies of the same documents, they are difficult to analyze, and errors are often introduced. Entity registration, sample inventory, and request & fulfillment are the workflows affected by this lack of proper data management. We have found that there are many excellent systems for entity registration and sample inventory, but these tools generally lack effective request and fulfillment tracking systems.
The standard request & fulfillment tracking process is familiar to most drug discovery scientists:
- A decision is made to test specific samples against specific assays.
- These samples are requested, prepared, and delivered to the assay scientist.
- Samples are tested, and results are reported.
Early-stage drug discovery organizations often have a hard time tracking everything from the request to the reporting of data, because this is typically handled by emails and spreadsheets. When mistakes happen, they are difficult to track down:
- Which samples were ordered for testing?
- When was the order for these samples made?
- Who ordered them?
- When were they tested?
- Against what assay were they tested?
- What were the conditions of that assay?
- When was the order fulfilled?
Workflow Informatics’ solution for this is the Workflow Request and Tracking™ solution (WRT). This software solution offers a simple sample inventory system coupled with request and fulfillment workflows. Underlying the web-based user interface are relational database tables that capture all the metadata surrounding sample request and fulfillment workflows.
Chapter 2: CRO Data Management
The introduction of offshore CROs into typical drug discovery workflows has made data management even more complicated. Roughly 15 years ago, the use of CROs by start-ups was beginning to gain momentum, and very rapidly took hold as standard operating procedure. Over the past several years we have worked with multiple “virtual” drug discovery companies, for whom all laboratory operations were performed by external CROs. This has added another layer of complexity to the drug discovery process.
There are two primary areas of research that are outsourced: synthetic chemistry and biological assays. The most commonly outsourced assays are ADME/PK.
Synthetic Chemistry Outsourcing Workflow
Let’s review a solid example of the request and fulfillment of outsourced synthetic chemistry. Generally, the process for request and fulfillment of synthetic chemistry targets begins with ideation and identification of potential synthetic targets by a chemist at the virtual pharma company. Each proposed molecule is registered in a virtual database, given a virtual ID, and its status is tracked. Statuses include proposed, requested, synthesized, abandoned. When it is determined that a proposed molecule should be synthesized, a request is submitted to the CRO. The molecule and a proposed synthesis need to be delivered. This is often delivered via a file server system in combination with email. When a molecule is successfully synthesized, the status is updated to synthesized, and it is registered into another chemical registration (chemreg) database that only contains synthesized molecules. The virtual database identifier serves as a molecular synonym in chemreg. The chemreg system tracks data hierarchically across three distinct levels:
- Molecule: The unique chemical structure.
- Batch: A specific synthetic instance of that molecule.
- Sample: Each physical containerization or aliquot of a batch.
For more detailed information on molecule, batch and sample levels, see our BioChemUDM publication. This method is adequate if the process is adhered to strictly, but it often breaks down over time. As an alternative, we would recommend a request and fulfillment application (like WRT), possibly in combination with an ELN system. WRT is backed by a database that can track each stage of request and fulfillment, along with metadata, providing accountability and metrics associated with the process.
Assay Outsourcing Workflows
Most of the CROs deliver assay results in multi-sheet Excel workbooks attached to an email. As discussed, this is not an ideal medium for the delivery of data. Furthermore, data sets are delivered in a wide variety of formats, often pivoted or separated into multiple tables based on experimental conditions (e.g. Species, Time). Data types are not always consistent across result fields (e.g. “N/A” or “ND” in a numeric field). In short, bad data practices abound. Over the years, we have built a great many parsers for these types of results using Pipeline Pilot, KNIME, and Python. Parsers can comb through the different sheets of the workbook, extracting important data fields, checking for adherence to data types, unpivoting, etc., and ultimately delivering the data in a format that is easily loaded to assay databases. In many cases, we have leveraged the APIs of various software for assay data (e.g. CDD Vault) to automate the upload of data. The lack of data standards seen across these ADME results is also addressed in our BioChemUDM publication. Workflow Informatics has implemented the BioChemUDM at several drug discovery organizations, and we believe the implementation of these standards greatly enhances the ability of organizations to perform data analysis and data migrations.
Managing CROs and the data they produce remains a challenge for most organizations. Organizations need a mechanism to ingest CRO data that enforces data standards and automates the loading of data into assay data repositories. When we started writing this retrospective in 2024, we had begun building point solutions for exactly this at various organizations. Those have since grown into CROW (the Contract Research Organization Wizard), our suite of tools and services for receiving, normalizing, and ingesting research data from CROs and other external partners. For a closer look at what unmanaged CRO data really costs, see our recent article, The CRO Data Tax.
Chapter 3: Data Warehouses
Drug discovery organizations tend to generate and store data in multiple systems and locations for a variety of reasons. For example, a chemistry ELN captures experimental information about reactions, but often sends reaction products and intermediates to a ChemReg system. Assay development takes place on one platform, but the methods are transferred to another platform better suited to HTS. One or more LIMS systems hold sample data. Sometimes data from these operational platforms are pushed to small data marts to make reporting easier.
However, for data analysis and modeling, organizations often prefer a single unified data source. As a result, many organizations have created data warehouses or data lakes. Ideally, the data warehouses allow quick input/output (i/o) and maintain strict data standards such as controlled vocabularies and consistent units of measure (UOM).
One of the reasons why we see so many different data sources is because there are many competitive commercial software vendors, internally developed software tools, and open source software that manage drug discovery data (chemical, biological, and assay data). Depending on research focus, one software is often better suited for an organization’s data than another. This is even true at the departmental level within organizations. The primary driver for internally developed software is the lack of commercial or open source software for newly developed research methods. Another driver of disparate data sources at organizations is the frequent occurrence of mergers and acquisitions, leading to the need for data consolidation.
Cloud-based software for assay data and chemical registration often has poor performance for ML and analytics projects. This is because of poor i/o speed mediated by APIs. Few of these software platforms have full-featured analysis functionality built in. Generic analysis platforms are often preferred. These analysis platforms perform better when consuming data directly from a data warehouse.
As a result, at Workflow Informatics we have created a variety of tools to automate the ETL of data from various data sources into a single data warehouse. In fact, we recommend this approach to support data visualization and analysis. Our set of tools and services for CDD Vault is an example of infrastructure that we have developed to support such efforts. The same thinking sits behind our Machine Learning Starter Kit, which pairs a curated data warehouse in your own AWS environment with automated ETL, so your models are built on data that has already been harmonized.
Chapter 4: Application Integration
The smooth flow of information across organizations depends on integration between different data sources and applications. This is more complex in drug discovery organizations, as the data types are not all simple alphanumeric data.
No single application platform has proven to be the best at each stage of drug discovery. We have found that most organizations maintain 5-10 scientific software applications, often including both commercial and in-house solutions. The applications center around the drug discovery workflow, which includes:
- Entity, batch, sample registration and storage
- ELN
- Assay data storage
- Instrument software (laboratory informatics)
- Analysis and visualization
- Business intelligence and data pipelining
A typical drug discovery informatics workflow: every arrow is an integration someone has to build and maintain.
In most cases, where two different processes are adjacent, information is shared between them. For example, the parent batch identifier is recorded in the sample database. These shared fields need to be updated and synchronized, unfortunately these updates are often maintained manually with spreadsheet outputs, manual transformation, and manual loading between adjacent data silos. A common project for our Workflow Informatics team is to automate the manual processes that link together adjacent applications. On occasion, we have also been called upon to create dashboard applications tracking the progression of samples and data across the entire drug discovery process. Additionally, we often build tools to gather metrics over time to report and visualize KPIs.
Chapter 5: Automation
Today, many drug discovery processes are automated with integration of robotic sample management and analytical instrumentation. Examples include analysis of samples, sample retrieval from tube stores, aliquotting and dilution of samples, high throughput screening, and calculation and reporting of assay or experimental results. Most robots take an input file that provides process instructions, and produce an output file that describes what was done, and any readings that were gathered. The instrument output file often needs to be parsed and joined with sample information.
There is a need for data management at the center of this drug discovery continuum that helps automate the flow of samples and data. Some modern LIMS solutions are beginning to accommodate more and more of these workflows. More recently, we have seen the desire to employ agentic AI to mediate automated drug discovery workflows. Many of our customers are implementing these types of solutions.
Drug discovery methodology is evolving rapidly and automation is a part of that evolution.
Chapter 6: Data Standards
Data standardization is extremely helpful in aiding automation, data analysis, and modeling. Without curated, standardized data, it’s very difficult to perform analyses and build models. Most scientists do not have the time or motivation to pay a lot of attention to data standardization, so it falls upon the informatics scientists to configure standards into software for data capture. Most of the best chemical registration and assay data platforms provide the ability to set up data standards from the start (designation of data types and controlled vocabularies). So, if a value is supposed to be numeric, it can be forced to be numeric. However, in our experience, most companies do not properly set these standards from the start. We have spent countless hours standardizing vocabulary. For example, we have seen about five different spellings for the word “Achiral”.
To simplify things, we have published the BioChemUDM in collaboration with IDEAYA Biosciences. The standard establishes structured guidelines for V3000 connection-table conventions (ensuring accurate representation of enhanced stereochemistry and complex entities), standardized naming taxonomies, units of measure, and hierarchical labeling rules across molecules, batches, and assay results. There are many other resources for the implementation of data standards in drug discovery informatics, including a variety of ontologies for bioassays (BAO), genes (GO), and drug targets (DTO).
For a more detailed review of data standardization in drug discovery, see our White Paper: “From data to drug candidates: Optimizing informatics for ML and GenAI.”
Chapter 7: Cloud Computing & Software
Without question, one of the biggest changes of the last 10 years has been the move from onsite servers to the cloud. The drug discovery industry has been no exception. Most of the top software providers in our sector have moved to the cloud. In many cases, they offer a multitenant or VPC option. True “on-premises” software offerings are now the exception. When we first wrote this series, we said data analysis software was the holdout, because it needs to ingest huge volumes of data quickly. That is no longer really the case. Cloud data warehouses and elastic compute now routinely handle analytics and ML workloads that would have overwhelmed an on-premises server room.
The cloud itself is not the bottleneck. Feeding it is. A typical research organization runs 5-10 scientific platforms (Chapter 4), and each now lives in its own cloud, with its own data model and its own API. Those APIs are generally built for day-to-day transactions, not bulk extraction (Chapter 3). Getting data between these platforms, or consolidating it for analysis, still means mapping identifiers, reconciling vocabularies and units, and handling chemical structures and assay results that generic integration tools don’t understand. Migrations add another layer: moving years of history out of a legacy ELN or assay system into a new cloud platform without losing structure or context.
Integration and migration are now the most common requests we receive, and our Platform and Data Integration and Migration Services address exactly these problems: migrating legacy data into modern platforms, connecting ELN, LIMS, registration, and visualization tools, and building data warehouses with automated syncs from otherwise disconnected systems. Several members of our team are AWS Certified, so we can help with the cloud deployment itself as well. The cloud made the infrastructure easy. The data still takes expertise.
Chapter 8: The Rise of AI
Full disclosure: when it came time to write this chapter, we asked an AI for ideas. It had plenty, and a few were even good. That alone says a lot about how far things have come. When we started this series, AI was something customers asked us about. Today almost everyone in our industry uses it every day, us included.
The same week the first version of this series was published in October 2024, the Nobel Prize in Chemistry went to David Baker for computational protein design, and to Demis Hassabis and John Jumper of Google DeepMind for protein structure prediction. It was a fitting marker. AI in drug discovery had stopped being a promising sideline and became part of the scientific mainstream.
Only as good as the foundation
Here is the part that tends to get lost in the excitement. Every chapter in this series has been, one way or another, about getting data into shape: tracking requests and samples (Chapter 1), taming CRO deliverables (Chapter 2), consolidating data in a warehouse (Chapter 3), connecting applications (Chapter 4), automating the lab (Chapter 5), standardizing vocabularies and units (Chapter 6), and feeding it all to the cloud (Chapter 7). None of that work was done with today’s AI in mind, yet it turns out to be exactly what AI needs. A model is only as good as the data it learns from, and an AI assistant is only as useful as the systems it can reach.
Four kinds of AI, one requirement
“AI” covers a lot of ground, so it helps to sort it by what it does rather than by the latest buzzword.
- Predictive AI is where Workflow Informatics started: QSAR and predictive models for potency, ADME properties, and assay outcomes. It remains the workhorse of computational drug discovery. What has changed is how accessible it has become. What has not changed is its dependence on curated, consistent training data. Our collaboration with Delix Therapeutics, using machine learning to predict neuroplasticity responses in the search for non-hallucinogenic antidepressants, is one recent example.
- Generative AI, including the large language models most of us now use daily, can draft code, summarize reports, and answer questions about notebook entries in plain language. It can also take the tedium out of the unglamorous parts of informatics, like writing the first version of a parser for yet another CRO workbook format. Generative chemistry models propose new molecules, too, but every proposal still has to be registered, made, tested, and tracked.
- Agentic AI plans and carries out multi-step tasks on its own: querying a registration system, checking inventory, submitting an assay request. In Chapter 5 we noted that customers want agents to mediate automated workflows, and many are now piloting them. From an informatics point of view, an agent is one more application to integrate. It needs the same well-defined interfaces and consistent identifiers as everything else in Chapter 4. Emerging open standards for connecting AI to tools and data help with the plumbing, but not with the data behind it.
- Perceptive AI reads images and documents. It can pull structures, tables, and results out of PDFs, scanned notebooks, and plate images, which matters to any organization with years of history locked in reports and slide decks.
An honest word about limits
AI is not magic, and the same failure modes come up again and again. Models trained on inconsistent data learn the inconsistencies: five spellings of “Achiral” (Chapter 6) are five different values to a database and to most models until someone standardizes them. Mixed units, missing metadata, and pivoted CRO spreadsheets don’t disappear because a model is involved; they just become harder to spot. Language models can give confident answers that are wrong, which is a real hazard when the answer is a structure, a concentration, or an assay result. And much of an organization’s most valuable data, such as negative results, failed syntheses, and full assay conditions, was never captured in a form a model can use.
None of this argues against AI. It argues for doing the foundational work first, and for keeping scientists in the loop to check the output.
What ten years have taught us
Looking back over more than a decade, the lesson of this retrospective is simple. The technology changes quickly: from on-premises servers to the cloud, from spreadsheets to integrated platforms, from QSAR models to AI agents. The fundamentals don’t. Clean, standardized, connected data is what makes each new wave of technology pay off, and it is what makes AI work. That has been the core of Workflow Informatics’ work from day one.
Is your data ready for AI?
If you’re wondering whether your data is ready for AI, or what it would take to get there, we’d be glad to talk.