Founder Stories: Zach Weinberg, Co-Founder of Flatiron Health & Using Data to Cure Cancer

In this interview Zach Weinberg, co‑founder of Flatiron Health, recounts his path from selling an ad‑tech startup (Invite Media, later DoubleClick Bid Manager) to Google, to founding a company that tackles the fragmented oncology data landscape. He describes how he and his co‑founder spent 18 months researching oncology, meeting thousands of clinicians, and then left Google to launch Flatiron. Flatiron is presented not as a pure data company but as a network business that sells a specialized oncology electronic health record (EHR) and an analytics layer that works on third‑party EHRs, enabling a unified platform covering roughly 20 % of U.S. cancer cases. Providers share de‑identified patient records, which Flatiron aggregates for benchmarking, research, and pharma collaborations (e.g., NCCN partnership). Weinberg explains the massive effort required to clean and normalize both structured and unstructured data—lab units, drug naming, scanned pathology/radiology reports—using a hybrid of human curators and tooling, likening it to a specialized Mechanical Turk. While acknowledging the potential of machine learning and NLP, he stresses that the messiness of real‑world oncology data limits their current impact; the focus remains on robust processes and tools. He discusses why Flatiron stays focused on oncology (high drug R&D spend, trial volume, specialty‑specific workflows) and why expanding to other specialties is non‑trivial. The company raised a $130 M Series B, using over half to acquire an existing oncology EHR to accelerate scaling. Looking ahead, Weinberg envisions growing the network to cover half of U.S. cancer patients, developing new use cases (including potential biotech/clinical‑trial platforms), and balancing provider‑focused services with life‑science research offerings.
Chapters
Well, welcome.
Thank you.
Um, so I'd love to, um, start with your journey a little bit because I, I just love your entrepreneurial story, right? Like guys starting companies in ad tech, uh, doing really well and then deciding to leverage that to then solve a big hairy problem. Uh, so tell us your, your story.
I'm gonna try and be short, uh, and sweet. Um, so quick background, uh, my co-founder and I started a, an ad tech company, software company back in 2007. We were coming out of Penn. We ended up selling it to Google in June of 2010. It was a company called Invite Media, which came and turned into DoubleClick Bid Manager, if you're familiar with the ad tech space. And then spent 2 years at Google. I'm going to try and move this up a little bit. There we go. Basically trying to figure out what we wanted to do next. And had always had this really strong passion for entrepreneurship and specifically for healthcare. Had kind of fallen into ad tech. And I always like to say, you know, you do 5 years of advertising and you kind of have to take a look and see, you know, what did I really truly accomplish in that time? And that was a kind of a serious, like, soul-searching exercise. And so, we did something very unique, I guess. We had a very unique opportunity. We spent about 18 months while still employed at Google essentially doing research. And we went around the country, probably about 1,000, meetings or so, flew all across the United States.
A thousand meetings?
With phone calls and in person. Yeah, probably something along those lines. And basically started researching oncology. It was a disease that was in both of our families and in particular Nat, my co-founders. And it was a space that we felt like we could get behind and want to be in for the rest of our lives. So our background in oncology was 18 months of homework that was probably 10 months of research, or 10 years of research, very, very condensed into a short time.
And how does one even start something like this? So you show up, say, hey, you're going to, we know a little bit, and then who are the first, and how do you start?
So, you know, our tip and trick for this was always just to ask for advice. Pretend like you're not actually selling something. So people enjoy giving feedback. They don't like being sold to.. And so we started coming up with ideas and presenting them to folks as ideas. Would you give your feedback? And kind of continued to tweak and tweak and tweak. And still doing it to this day, by the way. Until we felt like, okay, this is something that we could run with. And at that point, we quit Google and raised a round of funding almost from you guys. And off we go.
That's not the story I heard, but— okay, and so tell us about Oncology Cloud now. What does it do?
[Speaker] Yeah, so I'll try and set the context, 'cause Flatiron is a super complicated business, and everybody thinks we're always a data company. We're not a data company. So we're about 160 people. We're based here in New York. We've raised about $138 million from Google. We're their largest healthcare investment to date. At our core, we are a network business. And what I mean by that is, if you think of cancer care in the United States, if you are a patient diagnosed with cancer, you go and see your medical oncologist., and the information about you and the touch points with you kind of live in these little isolated buckets. You know, each provider, as we call them, is its own unique little silo. They do something to you, they capture some information about you, and then they go see the next patient. And our thesis was always, if you could connect these disparate hospitals, if you will, these disparate cancer centers on a common technology platform, and that means both data as well as touchpoints with those doctors. So, it's not just data, it's also the fact that we, we have touchpoints with doctors. There were a lot of really interesting things you could build on top. And so, when we think about Flatiron as a company, the foundational layer are things we sell to cancer centers. It's kind of an easy way to think about it. We sell software to cancer centers at a really, really big discount in order to actually build and grow that network, and that network now represents about 20% of all cancer cases in the US. So about 1 in 5 cancer cases we see. And then all of the kind of more interesting longer-term stuff we're building on top of that network. So everything from doing outcomes research to finding patients for clinical trials to linking our data with genomic data sources. You could think of those as layers on top of a network.
And the core network is what, that's an EMR? So I'm a cancer center, I have a cancer patient, I upload his or her information?
So we have two products. One is an oncology a company-specific electronic health record, which we sell to cancer clinics throughout the US. And the other is an analytics tool that works on EMRs that we don't own. So Epic and Cerner and others. So between the two, the idea is we can address pretty much any oncology provider that has an EHR, whether it's ours or someone else's. And in oncology, that's about 90% or so, and growing. It'll be 100% within the next 2 years.
And so, the idea of the network is that some of this is shared? So, some of the data is shared for research purposes?
Yeah, so if you work with Flatiron as a provider, so if you are a cancer center, one of the things you agree, in addition to kind of sending us your complete copy of your electronic health record, all the documents, we see everything on a nightly basis, you agree to allow us to process and de-identify your data so that we can aggregate it amongst the broader cohort. And in return, we are kind of providing folks with value props from the network itself. So, you could think of things like benchmarking or the ability to do research on broader cohorts that any one single cancer center might not be able to do. They only see, you know, 3,000 patients a year. We see a little under 700,000. So, there are Fred Wilson writes the best kind of network build-out, which I really love. He talks about the single-player use case and the multiplayer use case. And that's what we have. We have a single-player use case, which is we help you use your data better. And then we have a multiplayer use case, which is, oh no, by the way, now we've got this network behind us. Here are values that you can derive from the fact that there's 2,000 other doctors also sharing their data. And that's the single-player, multiplayer. Again.
Okay, and just to make sure I understand, so there's a benchmarking, but that you actually share data on an anonymized basis for research purposes. So if it's like this very rare form of cancer that I'm gonna see once a year, but for whatever reason in Kansas they have it 20 times a year, I'll be able to see what they've done, or?
So actually, funny enough, today we've spent probably 90% of our time focused on the single-player use case, as much as the multiplayer side sounds like super compelling and interesting. The reality is people just want like their problem solved now. And so we spend most of our time on the single-player side. I think on the aggregate, we announced a partnership with this group called the NCCN, which is the National Comprehensive Cancer Network. It's 25 of the largest cancer centers in the US where if you contribute your data, you will be able to get the broader data set for research purposes. Again, all de-identified, anonymous, and aggregated. But for a cancer center that sees 3,500 patients a year, you know, this is an order of magnitude, could be 100x what they would have themselves.
[Speaker] So, I assume you have to, you know, a little bit to Mark's presentation in a slightly different field, although I guess there is a big genomics component to all the cancer data. But, so do you see a lot of stuff like that, like the, just like crazy dirty data and lots of different formats?
[Speaker:JOSHUA ELKINGTON] Yeah, I would say we talk about all the fun software, but the reality is we spend most of our time cleaning data. It's very non-glamorous kind of work and infrastructure. So this is real-world data. This is the equivalent of what the doctor used to write by hand in a chart, but just now typed in a chart. But the amount of structured, normalized data that we see at the source is extraordinarily limited. We see lab values with different units of measurement. We see sometimes scientific names for drugs versus generic names versus, you know, brand names, for example. So, on the structured data side, there's this huge, what I would call, kind of data normalization effort that we have behind the scenes. So, we map. Much of this is actually done with people. And then we have this really unique infrastructure around unstructured data, which is all the notes, the pathology reports, where the genomic data actually ends up showing up. You know, you get a report, and when I say get a report, what that typically means is the report is faxed to you as the physician, and you read it, and then you hand it to your medical records person, and they scan it in. And so we see those, they're, you know, you can tell they're tilted, and sometimes there's like a crease down the middle, and all this kind of funky data. And so we have an infrastructure to go and extract key facts from those unstructured data points at scale. That's kind of a hybrid of tech and people. You could think kind of a specialized version of Mechanical Turk, for those who are familiar, using trained professionals with quality and feedback loops. Sometimes there's data we just can't get, and some of those because it's just not in the record, but we've taken data points. I'll give one just unique tangible example. So, in non-small cell lung cancer, or advanced non-small cell lung cancer, There are two known, these are somatic mutations, these are not inherited mutations, so this is the tumor. Your body has actually kind of inherited these mutations over time that if you have that mutation, there are different drugs that you can give targeted to those drugs, to those mutations. The testing rate is unknown because nobody knows how often people are testing. And if you looked for, it's an EGFR mutation is the example, if you looked for that in a structured field, you'd see it about 9 or 10% of the time. In our dataset, it's 99%. And so, we've gone in and figured out how to get EGFR mutation status out of the record to do it at scale. We track a 6,000-person advanced non-small cell lung cancer cohort every month. So, this is a clinical trial. It's not a randomized clinical trial, but it is a clinical trial in the real world kind of happening behind the scenes.
Let me get to the question we were discussing with Ron earlier. Why is it so archaic, like the state of the industry? And is that, you know, it's easy for us, like we spend so much time in the sort of like internet tech world and like this seems so, you know, and is now the tipping point and why is now the tipping point?
So, I may have like a contrarian view here, which is that doctors are not going to change. And at least not in any sort of timeframe that matters for a startup. Maybe 10, 15 years. So, when we first started doing this, we were doing our 18 months of research. I'll give you a little anecdote. You know, for us, we kind of said, well, why don't they just fill the eGFR thing out and just put it in a dropdown? It can't be that hard. You know, we do this every day. And then you go to the clinic. And we actually went and we did rounds. I probably saw 50 patients or 60 patients. We pretended to be med students, I guess. They introduced, they asked the patient, are you willing to have somebody in there? They say yes, then we walk in. And you watch the doc go through their motions of asking questions and trying to understand symptoms and issues. And this is cancer, so this is not an easy conversation for many folks.— some crazy, crazy meetings, folks relapsing and all this. And then there's another patient waiting for them right next door who has the same disease and the same issues. And for them to go and add 5 minutes of structured data entry to their daily workflow will reduce the number of patients they can see. Frankly, it reduces the amount of money they make, which is getting squeezed. And so our take on this was, You can get some incremental data entered, but the reality is the vast majority is I dictate into a microphone because it's fast. And the higher-level answer is EMRs, including our own, we're no better, are built for physician workflow and billing. They're not built for population health or informatics or all of this, and so you're kind of fitting this square peg into a round hole by doing a lot of, or we do at least, a lot of post-processing on the back end.
And it was interesting to hear you earlier saying that the way you clean up data, for example, is a combination of humans and technology. Curious about how you think about the role of machine learning and all those things in this world.
Yeah, this is probably the wrong crowd to say I don't think machine learning is important. But the reality is like, for our, so the context matters. Matt and I were trading emails earlier and I think he caught me kind of saying something that wasn't true, which is that machine learning and things like NLP and all of this matter for the context of the problem that you're trying to solve. And depending on the problem you're trying to solve, sometimes they apply, sometimes they don't. In our case, the underlying data is so messy. And so open to interpretation with things like negation or just the document's not, you can't OCR it. It's scanned and it's a little blurry. Our take on this is we should be building tools for trained professionals along with a feedback loop to tell them how they're doing. Machine learning and other technologies I think you can apply on top to make those people slightly more efficient.. But for our problem, and again, just kind of unique to us, we are a software company that builds really awesome tools. We're not a company that has a 60-person machine learning group, although many of the folks on our engineering team come from heavy machine learning backgrounds and are probably chomping at the bit wanting to use their skill set. But for us, at least, we're much more about kind of the proper process, the proper tools,, as opposed to machine learning, for example.
That's our take. Yep, absolutely. Last question from me is, what are you building next?
So, one of the reasons why we got into healthcare, one of the reasons why Nat and I got super excited about this space, is there aren't a lot of well-run software companies in healthcare that have kind of crossed that chasm. And what I mean by that is, there's a hell of a lot of 20-people-and-under healthcare startups coming out of incubators and whatnot, but most, if you look at the success, and not to poo-poo startups, but most fail to cross that chasm into like a successful healthcare business. And our take was always, great, let's solve that problem, because if you can cross that chasm, you have a protectable company for years. You know, our competition,— we like to tell this in our onboarding— the two biggest competitors for us, and they're kind of pseudo-competitors, they don't really do what we're doing. One is a company called IBM, you know, which really just wants to kind of sell hardware and services. And the other is a company that was started in 1832 that was actually doing like milk delivery, and they were a distribution company. So for us, it's about kind of being the backbone for the US for cancer data. And I think we're uniquely positioned to execute on that because we're not constantly defending against, you know, the ad tech startup over here and the next ad tech. Like, we kind of compete against our own ability to get shit done, which is a much more interesting problem for us, I think, because, you know, we have the team that can do it. So I think it's about, you know, winning, if you will. But we see 1 in 5. I'd like to see that be more like 1 in 2. There's a few segments of the provider market that we haven't cracked yet. It's about building that out and then kind of turning our attention to like, what are all the really interesting use cases on top? I'm sure there's plenty of things that we haven't thought of or haven't had time to build. And I think that's where it starts to get really interesting, right? It's what can you do with this totally new infrastructure that has doctor touchpoints and real-time EHR data and data processing? What are the cool things we can build? On top, and I think ultimately we'd love to run clinical trials. We have our crazy board meeting conversation, I have one tomorrow, where we always toss out like what's the craziest idea you could possibly think of. And for us it's always becoming a biotech company. Right? You know, you have like this differentiated infrastructure, you have real-time data, could you vertically integrate all the way through?
We'll see. And I realize I said that I think this is going to be the last question, but just quickly, so you raised this super large amount, the Series B level, $130 million.
Can you tell us about the thinking behind that? Yeah, so we raised a Series B, it's $130 million, and we used some of that money, more than 50% let's say, to acquire this electronic health record company that builds a specialized oncology EHR. And so, it was a really unique process where we were a 30-person company buying a 55-person company, which just, recipe for disaster I think in many cases. And the unique thing was that Nat and I had just been through it on the other side. We were, when Google bought our last business, we were about 55, so we kind of knew some mistakes not to make. So, we reused it to acquire this business, which got us to scale, is kind of a good way of thinking about it. We probably shaved like 3, 4, 5 years off of our roadmap. And now it's, you know, we're using the extra money to grow. And I think it's just a, you know, it's a unique industry where if you can break out, the opportunities are huge. The hard part is breaking out. The hard part is kind of getting to scale where people will trust you and believe in you. Will they just like take the meeting? You know, when you email them, will they meet you? That was, you know, one of our biggest challenges in the beginning.
Great. All right. I'll just— so you're oncology-based right now. Is there a reason other than just as your starting point that you're like limited to that? Or what would prevent you from easily expanding and what might you want to expand into? And how would you?
What's the, is it technology or marketing or? It's more market than marketing or tech. So oncology is a specialty disease. It's seen by specialty physicians. It's seen in specialty environments. So, you know, the clinics that we work with, many of them, they just do oncology. So for us to go to another disease, one of the issues would be you have to go find those doctors. I think more interesting is that oncology has a bunch of unique characteristics that make it right for our model. So the first thing is huge amount of drug R&D versus the number of patients. So if you look at that ratio of, you know, number of trials to number of patients, oncology is the largest. Basically take them, everything else, you add it all up, and then you've got oncology basically. So about 40% of all R&D spending from pharma is oncology-based. We're seeing drugs approved at faster and faster times. And so for us, we always felt like, the data would be extraordinarily, and the market, or sorry, the network would be extraordinarily valuable for life sciences, and that's one of our revenue streams is pharma. And oncology is uniquely positioned in that there's like hundreds and hundreds of drugs coming, and these are like really, really good drugs. These aren't like old, you know, some of the chemotherapies that add, you know, 3 weeks or 6 weeks. These are years or multiple years. So, I think it's a unique market that if you tried to take this model to something like cardiology, I don't think the revenue streams would be there. And I think the population's a little different. It's harder to find. The closest thing I would argue would be like neurology. So looking at like Parkinson's or MS or even Alzheimer's. But again, no drugs or very, very, very few drugs. So I think for us, we're gonna stick to oncology for quite some time.
You pick. Hi, I'm just curious, this process of normalizing records, obviously that's a huge, I presume, you know, labor-intensive backend process where a lot of the work is creating good workflows, good tools for knowledge workers to get the data normalized. I would think that you also want to do what you can, if anything, to encourage the practitioners, the doctors and the researchers, doctors and researchers to be neater. Is there an opportunity to do that, you know, in terms of, you know, the user interface or the experience, or are you philosophically against it? Do you just believe they should be able to do what they want and it's your job to figure it out?
Right. Like a few things, if you're gonna tell a doctor to change something they're doing, you need to tell them why it matters. And I think the key is, explaining, hey, if you do this thing that you haven't done and you weren't trained to do and you went to school for like 15 years, 'cause you're an oncologist, right, you're a specialist, you're gonna see value because of X. So, the key at the end of the day is tying it back to like some tangible benefit that that doc, that individual doc would get. And I think that's a hard problem to solve. There are, you know, for unstructured data, we may wanna find, let's say, 40 variables that we wanna go after. Maybe 3 or 4 you could really show like an individual doc how this helps. Most of it's on the research side, so it's hard to tie that through. We also don't want to be in the business of big brother our docs, or big brothering our docs. Like, the doctors in our provider network are the source of everything we do. And so, it's about finding the right balance. So, my answer is kind of like a qualified, you could probably focus on a few data points and really try and nail getting those. But at scale, I don't see it in any sort of immediate timeframe. A lot of the data points, for what it's worth, that we're trying, we are thinking about here are what I would call qualitative data points, which is like what's going on in your head, like the why, right? Okay, you chose drug A, why? 'Cause a lot of that isn't documented in the record. Hey, Zach, how's it going? Paul Piscinich from Bridgewater Associates. So I'm hearing you describe this vision of the multiplayer use case, but sort of the reality of the single-player use case. You're entering that inflection point headed into the new year. What do you see? Which part of the business are you most focused on internally? For preparing yourself and your company for that inflection? You said Bridgewater, right?
Yeah.
Our head of security came from Bridgewater. He's awesome. So, me personally, I, like, I don't really matter in this. You know, we're a 160-person company. So, the, like, what I can personally do at this point is pretty much interview people. And I spend most of my time actually, like, doing interviews. So, for us, the way I think about it is like where are people allocated? And right now, about 60% of our business is provider-focused, and then the other 40% is research and life sciences-focused. So, we're trying to like find the right balance, and funny enough, this is like a constant internal struggle of, you know, do you lopside one too quickly, or are you underinvesting, and like how do you find that that balance. And I don't think we have necessarily like the perfect answer. Outside of, we try and look at each team and understand, okay, if we added someone, like how much faster could you go? And then make some pretty tough judgment calls along the way. Personally, you know, I tend to spend a little more of my time on the research side, but just out of interest.
Yeah, I'm just wondering, in the context of data management in clinical trials, when you're trying to clean data, FDA has like a whole rulebook on how you actually have to clean that data and going back to physicians to correct data points. Do you actually have a feedback loop back to the physician when you're trying to normalize or clean your data?
So, let's make the distinction here between FDA registration trials and what we're doing. So, if you're trying to bring a new drug to market, and you need to test it on patients, and in oncology, we don't actually do A/B testing. You, it's unethical. So, you go against, or you don't do double-blind studies. You go against the standard of care. So, we don't touch that piece of the market. That's about, 4 to 5% of patients will go on a trial. We look at the 95% who are not on a trial. If we were to move into the trial arena, there's a lot of regulation that, you know, you have to follow in terms of the FDA. So, for now, our take has been trials should keep kind of doing what they're doing, and what we're going to do is take the infrastructure around everything else. So, that's, you know, that's the game. And then, maybe eventually, you know, you can actually run a trial on top using, like, FDA-licensed software, for example, or FDA-approved, I guess. Good. Last 2 questions. One here. Being a domain-specific EHR, is that correct? Yeah. How do you handle if a patient is not, is, say, going to a hospital? So, are you integrating with health exchange and is health exchanges, and is that a difficulty? Do you, you know, what's your challenge around sharing the data outside of your group and making sure that the right care can be provided? So, for context, it's like you're one of our customers. They always ask this question. So, for context, like a patient goes and sees their doctor, they, in oncology, there's a lot of things that your physician may not be able to do. I'll give an example. In multiple myeloma, which is a blood cancer, most people or many people get a bone marrow transplant. And so that's a, in what they call like an inpatient procedure. So you go to a hospital, they do it, and then you come back. So the reason why most people feel like that data is lost is because the information about that BMT comes back to the medical oncologist, the outpatient clinic, if you will, typically as unstructured data. So we see it, we see it either in the doctor note or we'll see it in a copy of the discharge summary faxed over, or brought, literally like in a manila folder, brought with the patient back, and they'll scan it into the record. So, we don't do health information exchanges, actually. Our take on this is the clinical record in oncology is actually fairly rich, but you have to know where to go to get the data. You can't just look for like the structured BMT field, 'cause it doesn't exist. With that said, not always the case, right? So there's exceptions to this. Not every patient's data makes it back. And for that, you know, our theory here is law of large numbers. So, you know, maybe not every patient, but our multiple myeloma cohort, for example, you know, is thousands of patients that we see. So in terms of significance, I think we have a set of patients where the data is super rich and we can actually use that as a proxy. Again, this is not about registering drugs with the FDA at this point.
This is about the infrastructure. And the last question goes to—
I thought you had one chunked out now. Someone else asked a question. Oh, okay. Is someone going to ask how we make money?
All right.
I think there's one there. So a lot of times with this data, you're probably getting, you know, are you getting pathologist reports? Are you getting radiology reports? Are you getting back to the actual data? Because there's usually a lot of, I guess, expert knowledge and differences in normalization between radiology reports from different clinics.
And how do you handle that in the normalization process? Yeah, so we get both. We see pathology reports, we see radiology reports, we see discharge summaries, physician notes, nursing notes, you know. Can you actually see the raw image data and the raw file? So we don't pull the raw image today because for us it's about the clinical interpretation, and so that we get out of the report. Maybe at some point it would make sense to start to pull the source image as well, but for now we stick to what the radiologist has said or what the pathologist has said. With that said, there's still like a ton of variability in that data, whether you're looking for like biomarkers or histology or whatever. And so a lot of the work we put in is in building tools and policies and procedures. It's not the most glamorous thing, but we have strict policies and procedures about, you know, if you have conflicting data points, what takes precedence, and they're all documented and written down, and we train folks on them., and they're shared with our research customers exactly, kind of like the provenance, if you will, of a data point. And for most key data points, like, we pretty much have it. There are some data points, specifically like the Ys and whatnot, where the data's really messy, and for those, we actually may not be able to get that data with our current setup. We may have to think about linking or doing something new. But for the majority of the important oncology data, we can get it.
At this point, great. On that note, thank you very much for being with us.
More from Joshua

Scientist Stories: Hans Waterham, The value of phenotypic assays in peroxisomal disorders

Scientist Stories: Joel Zlotogora, Genetic carrier screening programs for reproductive purposes








