Listen on
Overview
Biotech firms often struggle to transition clinical data from fragmented legacy systems into actionable insights or AI-ready formats. This disconnect stems from antiquated infrastructure, bespoke code that’s hard to maintain, and a lack of standardized data products, creating significant delays and preventing researchers from leveraging critical information.
In this episode of Data in Biotech, Ross Katz speaks with Jesse Paquette, co-founder and CSO at Tag.bio. Drawing from his extensive experience in computational biology and software development both in academia and industry, Jesse explains how organizations can overcome these hurdles. He details Tag.bio’s approach to building agile analytics platforms that enforce data product best practices and FAIR principles, making data accessible, interoperable, and reproducible.
The conversation covers modernizing legacy clinical trial data, preparing proprietary datasets for generative AI, the distinction between innovation in smaller agile pharma versus larger, more conservative healthcare systems, and practical steps data leaders can take to accelerate data harmonization and modeling for current and future demands.
Key Takeaways
Legacy data systems in biotech create ‘forever jobs’ and hinder AI readiness.
Many biotech organizations operate with decades-old clinical trial systems and bespoke code that are difficult to maintain or version control. This forces researchers into one-off data extracts and analyses, where results are often unreproducible and cannot be retained, making it nearly impossible to build reliable AI systems on top of disparate, unharmonized data sources.
Creating harmonized, version-controlled data products is crucial for accelerated insight and AI success.
The path to realizing value from complex clinical and biomarker data requires transforming raw data into purpose-built data products. This ‘middle layer’ models data into consistent, standardized formats (like CDISC or OMOP), automates preparatory tasks, and versions data snapshots. This ensures immutability, streamlines analysis for computational biologists, and provides a reliable foundation for AI applications.
Smaller, agile pharma sees the quickest gains from adopting data product best practices.
Organizations still in a growth phase, particularly those with a newly hired Chief Data Officer, are often ideal candidates for rapid data modernization. With established templates for common data schemas, firms can deploy solid data infrastructure within months, quickly moving data into the hands of researchers while simultaneously implementing essential IT best practices.
Data harmonization and modeling are the foundational steps for any AI initiative.
Before any AI system can effectively use proprietary internal data, the data must be harmonized and modeled for specific purposes. This involves resolving inconsistent schemas, terminology, and access rules across datasets, often requiring a human component to define precise nomenclatures for genomics, drugs, or clinical diagnoses, thereby building the ‘agentic AI’ readiness.
Related: CorrDyn provides data engineering expertise and data assessment services to help biotech clients transform their operations. Learn more about realizing data value in biotech manufacturing or how we help with digital transformation.
Full Transcript
Jason: Welcome to Data in Biotech, a podcast from CorrDyn where we explore how companies leverage data to drive innovation in life sciences. Every two weeks, we sit down with an expert from the world of biotechnology to understand how they’re using data science to solve technical challenges, streamline operations, and further innovation in their business. Today we’re joined by Jesse Paquette, co-founder and Chief Science Officer at Tag.bio. Jesse and his team are building agile, AI-ready analytics platforms designed to empower domain experts to explore and act on data without relying on engineering support. In this episode, we unpack how data mesh architecture and FAIR data principles are helping life science organizations modernize legacy infrastructure, unlock insights faster, and future-proof their workflows. Jesse also shares why smaller firms often also see the biggest gains from adopting harmonized, version-controlled data products. If you’re thinking about how to make your data stack more accessible, interoperable, and AI-ready, this one’s for you. Let’s get into it.
Ross Katz: Jesse Paquette, welcome to the Data in Biotech podcast.
Jesse Paquette: Hey, thanks, Ross.
Ross Katz: Awesome. Well, just to kick us off, would you mind giving us an introduction to who you are and what brought you here today?
Jesse Paquette: Yeah, sure. At the moment, I’m the technical co-founder at Tag.bio. We’ve been doing this for a while. We’re a software company in the life science and healthcare space. Previously, at the beginning of my career, I worked for a software company called Genedata in Basel. And so I’m guessing the audience might be familiar with that type of enterprise software. Then I worked for the UCSF Cancer Center for about four years as a staff computational biologist. So I haven’t always been on the vendor side, on the industry side. I’ve worked in the trenches in academia as well. And then between UCSF and Tag.bio, I worked at a company called Ayasdi in Palo Alto, bringing cutting-edge mathematical topological data analysis application to a number of industries including life science where I led the bioinformatics. It’s a lot of experience, I guess, in the Silicon Valley area, the importance of tech and the new concept of tech bio compared to biotech is something that we can talk about. I find that fascinating. But yeah, I think I’ve been in that startup space for the last 15 years now. So that’s basically where I’m at at the moment.
Ross Katz: Awesome. So what led you all to decide to found Tag.bio?
Jesse Paquette: Yeah, so I guess it goes back to the issues of data, which we might be able to get into. Data in life science, but also in healthcare and the challenges that persist after a number of decades. Say 20, 30 years ago, the concept of big data became reality with the sequencing of the genome, the advent of DNA sequencing, but even before then, the gene expression microarrays producing tons of data. All of a sudden, the industry got into this conundrum where it was being led by researchers, but eventually, Microsoft Excel couldn’t handle that load. And for enterprises who needed either the security or the extreme quality control over data, there was a centralization of data resources into IT or data units within organizations. Then there became a disconnect between the people who wanted to use the data, the researchers, and the people who were serving the data and maintaining the data. I think really that was the genesis of Tag.bio. These problems persisted, even though a number of technologies emerged, like Hadoop, if you recall Hadoop being a thing in say 2010 to say maybe 2014. I think the challenges there with data and making it servable to the audience and having the audience not do a bunch of things with the data that they would have to reproduce or go off into a black hole for one project, and all of that useful stuff can’t be retained. Tag.bio, we’re really focusing on the reusability of data, the usefulness of data for R and Python programmers as well as end researchers. And then the idea of the useful data artifacts. So the things that you do with data, either as an intermediate or as an end result, that these are versioned and attributed back to the data where they came from and can be accessible from then on as opposed to needing to be repeated.
Ross Katz: That makes a lot of sense. Can you walk us through the components of the Tag.bio platform and how it accomplishes the goals of making data more reusable, more use - more useful, not just for the people who are focused on the computational side, but also the people who are focused on the scientific side, and how the versioning and the attribution aspects of all it - all of it works.
Jesse Paquette: The biggest concept that we have comes out of the data mesh concept. If you’re familiar with data mesh, it was launched in 2019 with a seminal paper coming out of the Thoughtworks consultancy. While Tag.bio was started many years before then, we saw a lot of commonalities. So we’ve adopted some of the terminology from the data mesh community. One of those things is data as a product, or what we call data products. It’s based around this concept where the data should be considered as rigorously managed and versioned and served as software. A lot of times you get people just dumping data into buckets and all of a sudden things break downstream eventually because people change the buckets and stuff. If you think about data as a product, then you’re thinking about things like the development cycle, the maintenance cycle, and end-user use cases of that data. People call it an organizational philosophy as well as a technical philosophy. So it has to do with bringing domain experts into the design of data products. But what it means technically, each Tag.bio data product is served from say one or a few integrated sources of data. It represents a harmonized version of that data. If you think about genomic nomenclature or medical nomenclature, like ICD-10 codes or things like that, we want to make sure that the names of things are coming from controlled vocabularies or ontologies. So that’s done. Then the data is served up in a Kubernetes-type cluster system, where each data product becomes FAIR. Each data product is serving up of its own metadata about who made it, what its version is, what its data version is, and there’s a data catalog that can be built from each data product. Important that these data products are independent of each other so that no data product if it changes is affecting the essence of another data product. Therefore, this decentralized nature of data does present some needs for a global infrastructure of organization, things like access and governance. What we have are these different data products in our system, and these are deployed as Docker containers in a cluster. Then we have the overall organizational components for data governance, managing access, managing control and versioning of the data as well as a CI/CD system that helps these developers of data products continuously deploy and test their data products as if it were software. What it means technically for a coder is that each data product is a Git repository, and that Git repository contains a data modeling and ingestion element. This looks quite similar to dbt, where there’s a definition of tables and joins or flat files, and then how the different columns are modeled or potentially transformed. The other side of the data product in the same Git repository contains the API methods. These API methods can be generic of like, I want to be able to get a data frame out of this data product. Or they can be very specific, like I want to run a genome-wide association study on DNA variants, or I might want to do differential expression between a somatic cancer genome and a germline genome of that patient. Typically, the data products are built for analyses across large cohorts of often patients or samples. Rarely are the data products used for individual records analysis. So we never really got into the serving of say health records via FHIR, although it is something that our platform could do. With that Git repository tightly versioning all of the code, and hooking into the CI/CD system, this data product becomes maintainable and you can see in the process where the errors in the data product occur. If someone wants to institute a new R or Python plugin in that data product, they have to build a test for that, at least one test, in order to be able to deploy that data product. It’s basically a layer, what we call an application layer on data. It usually is compatible with the storage layer, which would be buckets or things like Databricks, Snowflake, relational databases, data warehouses, these would all feed in to the Tag.bio system and become data products.
Ross Katz: I think it all makes sense. So you’ve got this platform that’s enforcing data product development best practices in order to ensure that as these data assets are being created, that they’re being exposed in a way that they best embody the FAIR principles that they’re accessible, that they’re interoperable, that they’re reproducible. The question that comes to mind for me off the top is, what are the pain points that you see inside of biotech organizations that lead them to want to adopt a system like Tag.bio?
Jesse Paquette: One clear pain point that comes to mind would be legacy infrastructure. If you think about specifically say small to large pharma with regard to clinical trials, there’s a lot of legacy systems built around that. There’s a lot of SAS code that’s built around that that - some level of maintainability. And you have some people in those industries with what they might call forever jobs. Because that legacy system is probably not going away. But it’s also not very useful for the folks who might be doing computational biology, doing biomarker analysis. And these would all be business-critical things in the process of the trial. So you get a lot of extracts, which are not potentially not even done by code or you have to ask that legacy data system maintenance team to make an extract of this trial for you. And then from that point, you end up with people working with that data in typically one-off situations. And much of what they do, if they need to reproduce this survival analysis six months later, maybe the person’s gone from the organization or maybe they just take a while to have to figure out how to rerun their code or get it working again. All of that code that is working with the data and creating artifacts as data and transforming the data, is at best poorly maintained, and at worst becomes unusable. It’s in thinking about the full usage cycle of data as well as future uses. If you think about the AI trend right now, and the Gen AI trend, and you have teams coming in who might not be part of the biomarker team or the computational biology team, but they want to try to use proprietary internal data sources to help train an AI or build an agent on top of that data. And they don’t necessarily have the domain knowledge to properly interpret that data. That’s where a FAIR data source becomes really important. Having harmonized data fields, having data modeled as data frames. I think that’s a new pain point because I think you’re seeing a lot of orgs trying to figure out, okay, we’ve got all this disparate data, and we want to build an AI system. This is the grand, new CTO’s vision. We’re going to build a grand AI system on top of all of our data. And we get into the details. Every data set all of a sudden has a different flavor, different access rules, different access technologies, different schemas, different terminology. So the harmonization’s really important.
Ross Katz: That makes a lot of sense. So if you have these legacy systems and you’ve got these data pipelines, data processes where the code is very difficult to maintain and difficult to version control and it’s hard to understand the semantic meaning of whatever whatever pipeline or data system has been developed historically, how do you then take that and onboard it to Tag.bio in order to prepare for something like Gen AI or expose data that next-generation sequencing data or something like that in a way that makes it meaningful to all of the systems and all the other people who need to understand what’s going on there?
Jesse Paquette: Yeah. I’m going to go back to that clinical trial example because the trial data is in various forms. It’s first and foremost recorded in an electronic data capture, EDC. This is what the different sites of the trial are using to enter the patient information about each visit. EDC systems, if you take a look at the underlying schema of data tables within an EDC system, this is not in a standardized CDISC format like SDTM or ADaM. There’s potentially upwards of 100, maybe even 150 tables that contain information about these different patient records and visits. That schema is huge and unwieldy, and that schema is designed not for use, but the data schema is designed to present the user interface for the different clinicians at the trial sites to enter in forms. It’s all designed around the forms they’re filling out, not around what you’re you’re using. So most pharma in the context of a trial, have developed code systems to transform that EDC data into a CDISC format. The vendors themselves will do that, but strangely enough do not provide that data as readily as possible in the CDISC formats. Additionally, when you think about all of the biomarkers that might be measured, genome sequences, IHC, there’s 50 different types of biomarkers that might be measured in the context of a trial. This measurement is not done at the trial sites, but the samples are sent to a CRO. The CRO is now processing that, running the samples, collecting the biomarker data and serving back that data, typically in Excel spreadsheets. Those Excel spreadsheets, if for data scientists that might be listening, the very familiar with the problems. They all of a sudden it comes back in one Excel file with multiple worksheets and there’s lots of metadata headers and stuff sitting around kind of screwing up the column schema and the tables. There’s transformations that need to be done on that to bring them back into a useful system even to make it useful in Excel. Then you have to combine that with the EDC data or the trial data in CDISC format. At that layer, all of a sudden all of that raw-ish data, the raw trial info and the raw biomarker data is just being served up by a data team in these legacy-type systems, either a database or in some buckets. The computational biology or the biomarker teams access those different sources and they do the combination and the transformation. What Tag.bio will do is it will get a connection, a service account connection to the bucket storage and the relational database or the data warehouse system. When it runs, it builds together a comprehensive snapshot of all the data that existed at the time. It versions that. All of a sudden this data becomes immutable and any analysis that’s done further can be attributed back to that exact snapshot of data. And it models the data. It’s going to model the data for specific purposes. Oftentimes it will model the data down to a single data frame. In that scenario, it’s able to automate all of the work that would be the busy work for the computational biology team to just get the data into the data frame they need in order to build the survival curve or run the biomarker analysis, make box plots, things like that. That would include any downstream tools that they might be using as software. That would be Spotfire or a Power BI or say R Shiny type tools that they would be building downstream of that. All of those things require nice, clean, well-served data, and they can’t really do the transformations. That’s why we’re this middle layer between the data sources and the consumers.
Ross Katz: That makes sense. So you’ve built the data standards that are out there, for example, like the data that’s in the CDISC format into the transformation layer so that companies that have data sitting around in this format can onboard much more quickly? Am I thinking about that right? Or how does the onboarding process work, if you have these legacy systems in place?
Jesse Paquette: Right. You can imagine that if you’re dealing with a schema that is esoteric and unique to an organization, there’s some work involved. And we’re of course working on some AI tools to automate that, or at least accelerate that process to infer schemas and map it by creating this mapping layer more automatically. And we’re making good progress on that. But there is a human component in if the data is very complicated and never seen before, to do that modeling and that harmonization step. So we do some services there. We work with the customers that we have to do that for the data products. Now, that could be say the 20% case, but the 80% case is the data has been seen before and we’ve got templates already written for modeling data say CDISC or if you think about electronic health records like the OMOP format, these we have these modeling templates for and we already have built a number of useful API methods and applications and embedded type algorithms and analysis that can be automatically just added to a data product. When something is common and seen before, potentially a vendor data source like one of the IQVIA data sources, these types of things become much more easy to do and much more turnkey. The data product can be deployed within say a day from getting access to the data. Otherwise if we’ve never seen the data before, it’s in a esoteric electronic data capture 150 tables, that might take a combination of the AI automation that we have plus a developer say two weeks to one month to build something useful. So there is work involved and we’re trying to automate a lot of that and make a lot of it faster. But again we’re doing all of this to focus on the consumption and what is the purpose of that data and can we make that accessible.
Ross Katz: I think that makes sense. So you’ve got a platform that’s already accounting for the formats that you expect to see when you’re going into a new organization. Then you’ve got services that you can provide to help map between what exists today and help do the data harmonization, the development of that transformation layer so that all the data sources can link up with each other and you have this layer of meaning applied to the data so that everyone can understand what’s happening and how the different elements connect to each other. I’m curious, when you go into a new organization, how do you think about the division of data product from each other - from each other within a given organization? Is it at the type of data that’s being collected? Is it the individual experiment level? Is it preclinical drug discovery versus clinical development? How does that typically shake out?
Jesse Paquette: There’s a few reasons why we make decisions or we give advice to customers around deciding which data goes into a singular unit of a data product and which data should be kept separate. One of those reasons from an organizational perspective would be access rules. If certain trials, in the concept of GXP within pharma, there’s a lot of restrictions around need-to-know. Even if somebody is fully within an organization, but they’re not assigned to be working on that trial, then they don’t get access to that data, or they don’t get access to do analyses on that data. So oftentimes individual trials, even though they might have very similar schemas, would be segregated into different data products. Now, inside a data product, we can have differential access rules, but that tends to be a more complicated scenario. The simpler case with regard to access would be to segregate by who has access to which trial and each trial then gets its own data product. There are other times where we might take one data source and split it into multiple data products as well. For example with UCSF Medical Center, who uses our system on the healthcare side, they’re doing cost-effectiveness analysis, looking at trying to control the costs within a hospital and but improve patient care at the same time. In that scenario, we have three data products delivered off of their EHR plus their billing and accounting information. What that does is we have one view. Each data product represents a different view on the data where you might ask different questions. One view might be looking at cohorts of patients where every row, if you think about a data frame, every row is a patient and the data is all aggregated on the patient-by-patient level. But you can imagine you could go much more granular. You could go down to each patient encounter and see what the costs and the healthcare activities were done within each patient encounter, how the patients changed potentially in their care between different encounters. Then within an encounter, you can go down to the different activities, the different diagnostics that were made, the different treatments that were given. In that scenario, you could get drill down very granular to things like how much does it cost for IV Tylenol in a medical scenario compared to a pill Tylenol? Because there’s a lot of doctors out there who are pretty certain that the pill Tylenol is going to be as effective medically as the IV Tylenol. But how in a lot of hospital situations, the doctors want to always make sure they’re doing the very best thing for the patient and so they’re going to just quickly write the order for IV Tylenol. Now, the hospital’s going to think IV Tylenol is much more expensive as a cost to us, a cost to the patient. That’s the type of analysis you can do when you’re looking down at the most granular view of the different activities.
Ross Katz: Yeah. In one aspect you can look at data products as dividing up according to the people that are doing the work on it or who are authorized to do the work on that data. And then in another regard, I’m hearing you talk about the different grains of the data: at the patient level, the patient encounter level, and the patient - the activity within the patient - within the patient encounter level. This is my experience with data modeling is that it’s as much art as science, that there’s no - that it’s highly dependent on the use case and on the nature of the constraints that are being applied to that use case. I’m wondering if you have a thought process you go through as you and your team are thinking or are thinking about modeling out the different data products and just modeling the data generally that you think, this is the way that developing data models for life sciences is supposed to be done.
Jesse Paquette: Yeah. I think we have some great internal expertise which we’ve developed over time. People came into Tag.bio with a good amount of expertise in the industry and working with this data and then now with regard to applying our technology, that shifts again to a concept of best practices. These are the folks that have built out these templates to make these things more turnkey and so again it goes back to the common schema scenario. If the schema is quite common, we have that best practice in place and we don’t need to think about it or discuss much of it. Now, of course, if different use cases come up, then we have to re - come back and rethink how those templates work or how those API methods are going to work. It’s important to remember that if you go back to the data mesh concept, a lot of this has to be collaborative between different specialties. You need to think about the end-users. You need to think about the people who would be working with the data for the end-users, the computational biologists or the biostatisticians, and you need to think about the IT team and all of the different procedures that they would have. If you think about this on a human level, you want to interact and have conversations and continue to have meetings with all three layers. The data people are going to solve a lot of problems in the initial phase of working with data and modeling the data. The end-users will always tell you what they need. I want this report made. I need this analysis done. We’re publishing this paper or we’re doing this thing at a conference. We have this, there’s all sorts of use cases that you know. Then the intermediate layer, you cannot forget about them because they end up being I think the engine behind most of this life science research: the computational biologists, the biomarker specialists. They want the data coming out in data frames. They want to continue to be using R and Python. So for all of the modeling that you do in the data and all of the end results, the reports and things like that, there needs to be that intermediate access layer of being able to make a query in say a dbplyr type format for say R coders to be able to with their authorized on a data product to be able to make that query, start asking the data product for metadata. Okay, what columns do you have? Okay, I need to get these columns in this single data frame coming out. It becomes that iterative process where and sometimes on a human scale this will add time to the delivery of the final product because someone doesn’t have every minute of every day to talk about their issues. They’ve got other work they need to do. Our goal is to make it so they can focus on that other work. If we’re having meetings on and say a - sometimes it’s a daily cadence what we really need to sprint, sometimes it goes to a weekly cadence. I think you cannot forget the user experience and the developer experience type interviewing and the iteration.
Ross Katz: Yeah, that makes a lot of sense. Are there any particular customer segments or use cases where you see companies getting the most value from the Tag.bio platform?
Jesse Paquette: Yeah, I would say that given what we discussed earlier with regard to the speed of delivery of data products being dependent on the novelty of the data schema. With a known data schema, whether it’s in CDISC or OMOP or different types of omics formats, because we have these turnkey templates that set up the data product and bring in a bunch of algorithms already baked in, in that scenario, those types of customers - we think about all of pharma’s doing clinical trials except for the, I guess the maybe the generics producers and things like that. But if you think about the pharma from small to large that is doing discovery, getting possible compounds or molecules improved into clinical trials process, they have that data and everything is based around CDISC. There’s still the legacy of SAS in that scenario. I think that’s a sweet spot for our technology given the expertise that we have in the past and given the turnkey templates that make everything fast. I think on the healthcare side, this is a bit trickier because we have done a great job with one customer in healthcare, helping them do this cost-effectiveness analysis and really helping them understand their patient populations and how to improve the care and at lower cost. But as a, let’s say a small-medium enterprise, maybe we don’t say startup anymore, but as a smaller software company, it’s very hard to sell to a healthcare org. They are very conservative. They are dominated by physicians all the way up to the executive level. When it comes to innovative technologies coming through, I’ve seen countless companies with very useful tools for all sorts of purposes not last in healthcare. I think you need to be a major vendor. If you think about certain healthcare orgs that might have consolidated all of their infrastructure around say Microsoft. They use Microsoft for everything. They’ve got Power BI. They’ve got SQL Server hosting their data and they’ve got Microsoft sales reps right there constantly asking, “Oh, hey, we’ve got this new tool for this, we’ve got a new tool for that.” I think it’s due to conservatism as well to feel like a big tech company, even though they might be slow and less innovative, that they’re going to provide the reliability that they need on the IT side. You think about some big companies, maybe OpenAI right now. OpenAI trying to do pilots in a healthcare system, I think is going to be their worst use case. There’s going to be of course promotion and stories that come out from different healthcare orgs that are doing pilots. But when it comes to a long-lasting solution within healthcare, I’m not sure it’s going to work out there either.
Ross Katz: You’re indicating that this is indicative of a larger challenge of doing software-driven innovation in healthcare. Am I understanding you correctly or thinking about that right?
Jesse Paquette: Yeah. You could also, I mean if we’re really going to get a bit more scandalous, you can think about the elephant in the room, which is Epic Systems, and the, use my words carefully, the power they have in the market to ensure that there are barriers to entry for software vendors to try to work with that data, to do innovative things with that data, and trying to coerce customers always to use their own additional plugins or additional systems that may not be very effective or they may be great, but it’s a dangerous market situation for - and I wouldn’t advise any startup to take it lightly.
Ross Katz: No, that makes a lot of sense. And it sounds like on the clinical development side where there are established standards for the data and a sufficient amount of data collected in the biotech space is a good space for Tag.bio to play in terms of being able to bring a lot of value to bear very quickly because you’ve already got the established templates in place. Did I hear that correctly?
Jesse Paquette: Yeah, that’s right. I think for our sweetest spot would be smaller pharma that’s still in the mindset of needing to move quickly and get the data as quickly in the hands of the researchers as possible, but is starting to understand the need for IT best practices and maybe they don’t have someone in place yet who is properly leading - you think about the CTO or the Chief Data Officer role that exists. A freshly hired Chief Data Officer I think is our best pitch. Someone who - you need all this infrastructure, you need these best practices, because you were hired to implement all these things. Well, we can help that organization get going in a couple months and have that robust infrastructure to start serving their data for the needs. If we’re talking about a large pharma, they may have a lot of systems in place, a lot of legacy systems and various teams in place. There might be some displacement of other tech. When we get into a situation where we might be trying to displace some other tech that might be implemented there and pipelines, if you think about the data pipelines from the source to the end consumer, the large pharma’s been at this for 20 years. They might have found that they’ve tried and failed, adopted, tried and failed again and again and again. But they’re still trying, and they still have an active process of doing the next thing. So we have to catch them at a phase where they’ve failed to do something and now they realize they need something better. It’s always difficult when there’s that periodicity of interest.
Ross Katz: If it’s all right with you, I’d like to zoom out and just ask some high-level que - high-level questions about the ecosystem at large before before we let you go.
Jesse Paquette: Yeah, sure.
Ross Katz: Fantastic. Well, I - you’ve been in the biotech data ecosystem for a long time now. What’s the most significant shift you’ve seen in that ecosystem over the last 10 years?
Jesse Paquette: I feel like I’ve seen a shift in control of organizational power to the CTOs and the Chief Data Officers, even in the smaller orgs and even say between life science and healthcare. I feel like there is now a ownership of all data resources on the in that centralized team. I think there was a period where it felt like there would be research ma - say research executives or data management executives that would maybe be an intermediate layer. I’m sure this still exists at some orgs where you have IT which is really about helping people support their email and single sign-on and security. Then there would be a data team which would be adjacent to IT but not part of the same executive structure. And then there would be say the different business units and the different researchers. I feel like that research IT is merging with the central IT. A lot of power is being consolidated there. I think that’s good and bad. I think a lot of good decisions can be made from that. Big ambitious decisions can be made because the budgets are larger, there’s awareness of all the systems that need to be supported, and there’s less redundancy. The challenge I think with that centralization of data ownership ends up being that the use cases and the different business units, they tend to be slower to serve and they tend to be let’s say less specific. Where the central IT team - we see this in a few customers. The central group says, “Well, we’ve got this Power BI dashboard, or we’ve got these Spotfire dashboards. It’s built for this type of data, you have that type of data, there you go.” And then the researcher says, “Well, this doesn’t solve my needs. I need this report, I need this thing, I need this thing.” Then they have to again go to a person and work around the system and potentially try to justify why they can’t use that dashboard system that’s already been deployed and lots of money’s been invested and they got a whole team of people who are working on that. I think there’s this push and pull with the last mile, the concept of a last mile problem where the people who really want to do the things with the data, they have very specific needs, not served well by the generic distribution system. So this I think is a trend that is increasing and something that needs to be addressed still. Also, there’s always emerging data. You think about the emerging data of the last couple years, there’s going to be new types of data coming soon. This is not a change in the industry, this is the standard. It’s very exciting. I think it’s a lot of us, I think it’s a big reason why a lot of us say from a technical or a coder or a software perspective are still passionate about being in this industry is because these new things emerge all the time. You get really excited about what you can do with it. I think obviously AI, obviously the Gen AI and the agents and the systems that are being developed, they’re great for understanding the knowledge of everything on the internet and maybe talking like a person, but can they really understand the structured data or the unstructured data, proprietary data within organization? I think there’s a lot of advancement in that right now. That’s pretty exciting and I think it will change things. I’m not on either side of the AI doomsday scenario versus like this is going to make everything better and no one’s going to need a job anymore. Maybe that’s both. But I’m in between. I think I’m looking forward to hearing about very positive, successful, robust use cases that are scalable and extendable to different orgs even though they have different data and different needs. But I am going to be skeptical of just like you’d be skeptical of a university report saying that this NIH-funded researcher has discovered a molecule that cures cancer. You see these university reports and then you read the actual paper that the person wrote and it’s like, “Okay, they had amazing survival rate in mice.” This is preclinical. You’re going to get a lot of bombastic AI reports of, “We have saved 10% of patients” or “We have improved efficiencies” or accelerated discoveries of molecules like the idea of the protein folding or the screening of compounds or antibodies. These are good applications. I think the news is going to be overblown based on how much money, specifically marketing money, is flowing around right now.
Ross Katz: It sounds like your default approach is just to discount whatever news you hear until you’re able to touch it with your hands and see the value that it’s driving, which I think is a reasonably conservative approach to what you read on the internet. Are there any changes in data standards or regulatory frameworks, like related to biomarkers for example, that you think are going to shape the development of platforms like Tag.bio?
Jesse Paquette: We are interested in seeing organizations like the FDA, and I don’t know how the European Medicines Agency does this, but there’s been a, let’s say a domination in the trial space around SAS. To think that you would need to use a proprietary vendor to just submit your trial to the FDA, the EMA is something that doesn’t really fit well with the way technology exists today and so I’ve seen reports coming out. Now, the current political climate probably changes everything, but I would like to see an opening of submission formats for trials to the FDA. I think the idea of say maybe more discovery research or academic research, if you look at the data repositories that are out there, they’ve done a pretty good job of putting together formats. If you think about the different sequencing formats or the different omics types formats. The challenge I think with all of those different data is not so much processing the data from that common format, but rather understanding the experimental context. Because if you’re looking at a specific experiment and it only had these types of patients or these types of genetically engineered mice, then it’s very difficult to extend that or combine that with other data sources. In general, I’m hopeful that the standards, all the way to the FAIR standards, I think that it would be nice to see these adjust and become more concrete and hopefully still remain flexible. I don’t see too many problems with regulation and data standards as it exists other than potentially given the context of all the other things I talked about today, the idea that data is hard to work with.
Ross Katz: Awesome. And for data leaders in biotech who are interested in the ide - in what you proposed around data mesh or are looking to leverage advanced AI more effectively, are there a few practical steps that you would recommend people take in order to make sure that they successfully adopt these approaches or are able to get the most value from them?
Jesse Paquette: Yeah. I think it comes to the harmonization and the modeling of the data. I think everything stems from that. That goes back to the human usage of that data as well. To be able to have, specifically around say different nomenclatures, if you think about genomics type nomenclature, you have nomenclature around drugs. Are you referring to say the protein? Are you referring to a protein with an amino acid change? How much of that context does the AI need to know, and in which case how are you going to consistently define that? Are you going to use a specific genomics nomenclature of, “Okay, it’s this gene with this specific mutation”? If you go to the healthcare side, I think that’s an even bigger challenge for the AI systems because the definition of a patient having type 2 diabetes is not as clear as you might think in terms of the diagnosis. There’s possible comorbidities as well, but if you look at the ICD-10 codes, there’s not just one ICD-10 code for any given disease or disorder. So then you need to start making sure that you have these translating agents. I don’t think I’m alone in the industry to think that the agentic AI and having these agents being able to translate the data and control the data access and schemas for AI is going to be critical.
Ross Katz: And for people who are interested in learning more about Tag.bio, where should they go to learn more?
Jesse Paquette: Well, our website is easy. It’s tag.bio. That’s a great place to start. I’m not sure if connection information would be deliverable in this context, but my email address, you can email me directly. It’s Jesse, J-E-S-S-E at tag.bio.
Ross Katz: Awesome. Well, Jesse, it’s been great having you on. I really appreciate the time and look forward to connecting down the line.
Jesse Paquette: Yeah, thanks so much, Ross.
Jason: And that’s it for this episode of Data in Biotech. If you enjoyed the episode, please subscribe, rate, or leave a review in your podcast platform of choice. See you next time.
