The Evolution and Future of Healthcare Data and Building a Vertical SaaS Platform: In Conversation With Dr. Arif Nathoo
I’m kicking off a Vital Signs series following up on a few pieces I wrote on pharma software and data including Real World Evidence and R&D tools. I can’t think of a better person to start things with than Dr. Arif Nathoo, co-founder and CEO of Komodo Health, a fascinating healthcare data company most recently valued at $3.3B. We discussed Komodo’s journey from a single application to a platform, why EHR data is overhyped, and where healthcare data is headed. Check it out on Apple or Spotify.
Arif got his undergrad, MD, and MPA degrees at Harvard, before working at McKinsey for seven years in the life sciences practice and then founding Komodo Health. Komodo marries comprehensive healthcare data with algorithms and applications to improve healthcare. My conversation with Arif was wide-ranging touching on patient ownership of data, challenges in using data for healthcare research, and how he’s thought about building a platform company. We also hit on how he thought about the commoditization of underlying data vs. applications of that data in building Komodo.
Check out the full transcript below:
Arif, you have an interesting background. You got many different degrees, then went the consulting route, and then started Komodo. How did Komodo come about? Where'd the idea come from?
The most amazing thing that we learn in healthcare is how much it's constantly changing and how it never fits the expectation of what we want. I started in medicine because frankly I was so passionate about patient care and what we could do to improve patient outcomes at an individual level. It's why everyone goes into medicine. It's why people want to be doctors. It's why I wanted to be a doctor since the age of five.
But in medical school, I realized just how messed up the system was. I was studying medicine in the early 2000s when we were seeing the rise of EHRs and all the great and terrible things that came with it, from medication errors to orders that ended up in the ether somewhere, and the impact that could have on patients.
And while it was just in its infancy and growing, you could see where technology could go and that future that was very possible. I did the thing that was unpopular at the time and said, "I'm going to forgo residency. I'm going to get a business residency. I'm going to really understand how business works."
Yeah, I feel like that's more popular now, but I'm sure at the time-
Oh, it is. Three people out of my class of 165 did not do residency. One's a noted VC, one went to a hedge fund, and there was me who became a consultant because I was fascinated by the healthcare system. So it was definitely not the path well-traveled. Now it's socially acceptable apparently.
At the time it was about figuring out how to put all of this to work. As a consultant, it was amazing to see how care was delivered and the fight that exists between insurers, providers and big pharma companies. They're all fighting for a different piece of the pie. Then at the center of this is this poor patient that's at the behest of all of these massive enterprises trying to grab the healthcare dollar. And I thought that was not only incredibly fascinating, but a massive disservice to patients.
I think every company thinks that they operate in the service of patients, and they do, but they also operate in service of their own profits. And I think that has these implications at the intersection between two entities where the patient sometimes loses. My fascination has always been in the way that data and technology could transform that.
Our system is massively fragmented. You see a patient here, you see them there, and then those two systems don't speak. I got really interested in saying, "Hey, could we stitch these journeys of patients together to understand what's happening to them and what's driving better and worse outcomes?" I devoted my career and my time to that problem.
We started Komodo with that thesis, that we could trace these journeys, we could understand what was happening, and through that process improve patient outcomes. That was the motivation.
I imagine you got good exposure to the data landscape while you were at McKinsey. When you were starting the company in 2014, I'm sure there was one universe of data that was available. Now over the last decade, that's changed a lot. How has the healthcare data landscape evolved over the last decade?
We'll start with the foundation. For 40+ years we've used EDI transactions in healthcare, what we call claims, submitted claims, remitted claims on the medical side and pharmacy claims, which are processed to dispense medication.
Those claims have been the foundation for all healthcare research for decades. That's because it has a few benefits. One, in the US at least, because reimbursement's tied to coding, people code really well.
This is not true of every other country, but in the US people are really aggressive about coding, especially in certain areas, like in ophthalmology, there's a code for everything. It's very different, for example, than in heart failure where there's not a lot of specificities.
But the notion of coding is something that we see in a claim that's very different and meaningful. We can also tie it to a de-identified patient, we can tie it to a provider, we can tie it to a facility. So it serves as a good foundation. That's where we started 40 years ago.
When we started the business in 2014, everyone was enamored by all these other cool things, like electronic health records that were getting digitized and structured in great ways. We were seeing lab results and lab testing becoming more available. It was not just hitting the paper, but somebody would digitize that and make that available.
The whole idea was like, "Wow, there are all these new great things beyond the claim that have come up." So when we started the business, we actually went for the boring and obvious stuff — we wanted to revolutionize the claim. For a lot of reasons, we saw a huge opportunity to get that right because of how much was being innovated on with everything else.
Not only EMRs and lab results, but how much was coming out of devices, how much was coming out of patient-reported outcomes like surveys. The notion was that there was going to be this massive proliferation of brand-new sources, new digital health apps, new formats, but those things needed to be brought against some sort of backend that allowed you to perform studies at scale.
We had this mindset that we needed to build some backend that enabled all these great new exciting datasets to come to life. That's why we made our bet on something that was old and boring. But at the same time, a huge enabler for digital health at scale.
In thinking about marrying all these different data sources that exist it sounds like you were quite thoughtful about the most helpful backbone or starting point to have. Claims data probably is the most ubiquitously available and a backbone for building patient journeys. It makes sense to then marry everything else on top, which I know you've done over the years in adding lots of other data sources.
I'm sure others were looking at claims data. Some of your older competitors had been around for a while. What was the opportunity you saw at the time in 2014 that made you say, "Well, even if this has been around a bit, there's still an opportunity here?”
When you look at a patient from the lens of a claim, you have no idea whether you're capturing 2% of that patient's life or 100% of that patient's life. So in the healthcare world, and especially in life sciences, they've created these funny terms. One's called closed data, which somehow implies that because it's closed, you're seeing the whole life of the patient. And they contrast that with open data, which basically means you're sampling the patient.
We don't know the sampling bias in open data. But ironically, the more "closed data" we looked at, the more we realized that there was a massive bias in that data as well, so the reality is that nothing is really known about what the true denominator of a patient's life is.
But this is so important. If I'm assessing the value of one drug versus another, I need to know that my denominator is accurate. If I'm trying to say one medical intervention or one healthcare intervention is more effective than another, I need to know the total cost of that patient after they leave the system that's capturing the data to other systems that may be facing the pain of that patient's cost.
So we don't have great standards to validate the fidelity of a patient’s life. A lot of these legacy aggregators would say, "Hell, here's some patient data. Go have fun." We don't know. Is this all the patient data? Is this some of the patient data? Is it accurate? Is it biased? How does the bias affect your study? That's been historically the challenge.
On the other side, you had a lot of these payers that would provide payer complete data sets. But the problem is that these payer complete data sets are also full of holes. There are carve outs for the PBM, there are mental health carve outs, there are dual eligibles, so they're potentially getting care through a whole different vector that you're not seeing. Nothing that people think is closed is closed.
We walked into a situation where the data was not at the level of fidelity it takes to do great research. And we said, "What if we were able to vouch for how much of a life we could see?" It's not a crazy innovation other than to say, "Just be honest.” I think I'm seeing 2% of a patient's life here. I think I'm seeing 100% of the patient's life, and I'll tell you the difference between the two. Then you can decide as a researcher what you want to use as you're making decisions on how to study.
That's the lens we approached this in. We said, "Nobody's doing this. Nobody's able to vouch for this. Nobody's very complete. Nobody's very comprehensive. How do we do this better?"
There are all these corners of healthcare data that I'm sure are hard to get access to but are crucial to running a real analysis. It seems like you and the team have expertise in interpreting this data and knowing where to find some of these corners of healthcare data, whether it's specialty pharmacy, dual eligibles… There are endless exceptions to the general rule within these data sets.
Absolutely. The things we care about, the three dimensions I think are important — obviously breadth. If you want to draw conclusions on healthcare in this country, you need to see a massive amount of lives. We cover 90 to 95% of the population in very deep ways. Then the depth. We need to know how much of that life am I seeing and can I get to that 100%.
The other thing we look for that's important, in addition to these two that are obvious, is redundancy. Some actors see part of the life in a certain way and another actor interprets it in another way, so a lot of what we focus on is making sure that we can see across the intersectionality of the payer's view of things, the provider's view of things, and then all of the technology companies between the two to get a true sense of what we think is happening with the patient.
You've released a lot of products on top of this. Every time I go to your website you've got two or three new products. How would you summarize what Komodo does today and how that focus has evolved over time? Maybe we can start with your relative focus on de-identified and patient-specific data.
I'll start with our products first because I think there's a misconception in the market that somehow more data matters or that the largest dataset is the best dataset. This has been one of the big problems in healthcare — you can get a massive amount of data, but you often have no idea what to do with it. We see this with our clients. A lot of them will go out, they'll license data from a legacy aggregator, they'll hire a bunch of analysts, they'll realize their analysts can't do it, so they go higher and spend a lot of money on consultancies. That whole process is expensive. It takes a lot of time.
We realized that we are the best arbiters of our underlying healthcare map, which is not only the data, but a lot of the imputation and insight that we put on it to make it valuable. I'll explain what that means in a minute with some examples.
On top of that, we create these software experiences, these applications that folks can use for various use cases. We started with one application in one specific area and then we realized that other teams needed more fit-for-purpose applications and we started to build these applications but on top of a common platform. That allows us to solve a bunch of different use cases, but with the data and the insight that you need to drive a better outcome.
We focus on creating these applications to enable a wide variety of use cases. That's what we sell to market. I think it's a far better experience and product for a user than just consuming data, then doing a lot of work on top of it. That's redundant. That's actually subscale compared to what you can get through great software. That's where we started.
The second part of your question is focused on this idea of de-identified data versus identified consented data. One thing to help your listeners understand is that there are two regimes in this world. One is this 40-year-old standard of de-identified data under HIPAA, which allows us to strip out a lot of the identifiers that make it possible to know that this piece of information refers to Arif Nathoo. And my job is to make it impossible for someone to be able to do that.
But the more that I grab other pieces of data and link that together, the higher that re-identification risk becomes. So we live in a world where in order to preserve privacy, we want as rich an information flow as possible, but one that does not violate privacy. We care a lot about that. We believe in that. We exist in this de-identified world, the standards set by HIPAA, because it enables healthcare research at scale, and it has proven year over year to lead to amazing insights that benefit the public. We think that channel is valuable and will persist.
On the other side, we've created this incredible opportunity for patients to take custody of their data and the richness around it, to bring all of it together for their own benefit, and then choose what to contribute to for research. We think that path is starting to grow in awesome and fascinating ways. I think over time, we'll see more and more patients getting involved in that process.
We are seeing the strong arming of a lot of old school institutions to be able to provide that information we think is critical to that process. So that information is already starting to make its way into our products and services in a way that allows us to bridge these two worlds in a way that I think benefits patients in the long run. We're thrilled about that. These two sides of the coin are where healthcare data has been and is going in the coming years.
I imagine with the specific patient data, when you've consented the patient, you can then go fill in gaps much easier, because they have the right to that data. As you think about building the business going forward and what it will look like in 20 years, I'm sure a lot of that is contingent upon what regulation looks like on the data side.
You probably take a step back every so often and think about this stuff. Where do you think we're going from a regulatory perspective on the data side and how does that impact what you think Komodo will look like down the line?
The beauty of the two worlds is that they're not in conflict with each other. There's a lot of talk around “How do we continue to revise and model HIPAA in a way that's consistent with our expectations of privacy?” And I think that will continue to happen.
I think it takes a collective belief that we need to improve HIPAA and strengthen the protections in there. And I think a lot of us have seen, as we've observed GDPR and CCPA and other kind of regimes that are focused on privacy, there are going to be profound implications for how the de-identified world works.
And we think that is good. That's good for patients, that's good for the de-identified world. Because if we can continue to build trust that de-identified insights at scale can improve public health, which they can… I'm not here to serve you an ad, I'm here to help improve the ability for someone to diagnose a patient with a really rare disease. That's great for patients. And we think that model will continue as we create the systems and regimes to do that.
On the other side, I see the patient-consented world growing and I think this is the most exciting driver for the consumer. At the same time, there are massive barriers still. It's theoretical that they can get their data. They still have to memorize every login. They still have to know and remember which providers they went to see. And half the time, when you ask the patients to come up with a list of providers they saw, they get like 30% of them right.
So the reality is that there's still a lot of friction in the process of that. And I think as we solve the friction, we are going to see an improvement there. My belief is that that regime will only get stronger and more focused as we push into that.
The other problem is that it takes a patient caring. We see 330 million+ patients, which is pretty much census in this country. How many patients are out there chasing their records? One million? Two million? It's not 20, it's not 50.
So the problem we have is generally an apathy towards this. And I believe over time that will evolve. We tend to only care when we're sick. But when we're not sick, do we care? Do we want those records? Do we care about tracking our fitness and our health in a different way? The jury's out on that, and I think over time we'll see a population attitude shift and then policy to accommodate that. That's my expectation as we venture on that side.
I think the point you're raising on patient consent and data, where it's a small sample size today, relative to the kind of de-identified stuff you're doing is really interesting. Are there already use cases for which patient-identified data is helpful and being used by companies like Komodo and others? And where is it not ready for prime time?
Absolutely. It's really valuable in the rare disease space, in highly motivated small populations of patients that face very, very complicated journeys. A, they're highly motivated to bring their data to the table. B, they believe that through that process they can achieve better care. They can find clinical trials faster and easier. They can inform their providers based on everything that they've seen and done, what their future journey should look like, and use that as information that they need to bring to the table. We see it there, we see it in oncology.
So we think that there are certain places where disease burden is high and meaningful at a patient level, where patients have a high degree of motivation to bring that to the table. Then on the other side, the consumer of that, the pharmaceutical company that's recruiting patients for a clinical trial or trying to understand where standard of care is not being met, there is an excitement to bring that in when they see the tie to their ability to be more successful.
The challenge is in that layer between the two. That's where companies like ours fit. We partner with companies that bring consented information in because we believe those pathways are important. The Picnic Healths, the AllStripes of the world. They really believe that they can not only bring that information to the table, but companies can benefit from seeing that. And we love supporting them because we see that already starting to change the practice of how companies think about consented data and using it to create a better experience for patients.
I think one thing you alluded to earlier was, you started with one product and then it seems like you found ways to serve tons of different stakeholders today in healthcare with data. You started out in pharma medical affairs and I'm sure a lot of investors were always like, "Is this just a medical affairs company? Where else can you do this?" And clearly, you've proven that wrong. I'd love to hear that origin story in medical affairs. Was it always clear, “Okay, here's what acts two through — I don't even know what number we're at — are going to be?” Or was that an iterative process of learning along the journey?
When we set out to build this company, we had a strong thesis about the business model. This was a very unpopular thing. We had very clear layers. We had these big legacy data aggregators that just go out and resell data. We had these big AI companies. I think the biggest example in 2014 was Watson. I thought, "Oh, Watson is this great AI company." And then we thought we could solve everything with, at the time, Tableau or Spotfire. BI was in this state of maturation where you had real fast BI companies, you had real data aggregators, and you had these real professional AI companies in between.
And when we went with this vertical slice, we said, "We're going to take just the data we need. We're going to push it through our own very specific algorithms and we're going to build an application experience that's very specific here." You had to believe that by doing that kind of vertical slice you were creating an offering that was emblematic of a thesis change. This was the big thing that we were fighting. We were saying, "Hey look, you have this highly commoditized data product right here." And because it's highly commoditized, everyone is de-commoditizing the analytics. That's why you had this plethora of companies, like a Clayton Christensen in business school 101, which is this idea of commoditization of the value chain.
In our view, if we could take and de-commoditize the analytics and create an application experience that was truly superior, we could use very generic data. That's how we started the company, with that belief, and we proved that in medical affairs. Why? We understood the use cases, we built fit-for-purpose, and when we went to investors, we didn't have any aspiration to be anything more than a great company serving medical affairs. Nobody would push us because we said, "Look, the TAM here is huge." Sure, it's not a $10 billion TAM, but vertical SaaS is not all about $10 billion TAMs.
Vertical SaaS is about grabbing share, getting to high growth, getting to good profitability in a reasonable timeframe. Even if I'm just a company that pulls a few hundred million in revenue, I'm still a company worth thinking about in a billion-dollar TAM situation. And that was good enough.
By the way, in 2014, we'd seen all of these other SaaS businesses that were easy, like CRM, easy, like BI, easy. This is hard because I'm stealing share from services, I'm stealing share from aggregators. It's a very different type of place to steal those first few customers. But then to truly build a scaled SaaS business, you're forcing a complete business model change.
I was like, "If we can do that, we can prove to everyone that we could be a hundred-million-dollar-revenue business.” That was the thought in 2014. And guess what? There were a lot of investors that were willing to underwrite to that revenue range because they said, "You can be successful in a vertical business that has a billion-dollar TAM. But even if you're only a 10% share, we can see you as a reasonable business." We appeal to that type of investor that could get that thesis, that could believe in that type of business.
What changed over time is our aspirations grew when we realized that we had this great application, and now everyone's starting to copycat that application. That forces de-commoditization of something else, and that was the data. That's where we started to build the advantage and built our platform. And now we've truly de-commoditized the platform. We have a huge advantage.
How'd that shift happen? It sounds like you started thinking that the differentiation would be, “Everyone's got the same data; how do you make this data usable?” Then at some point you realize, "Actually, maybe everyone doesn't have the same data." How'd you figure that out?
That was the fun part of our journey. In 2016, we started to get access to datasets that weren't on the market yet. This was because people had started to hear that we existed, we were doing this work in medical affairs, it was interesting to enough folks, and I had spent a lot of my time really understanding the nature of how de-identified patient-level data was being used across the industry. I found a lot of corners of the market that were massively underleveraged.
Especially with payers, because a lot of payer-derived data is not really infused in the way that pharmaceutical companies work, for a lot of reasons. Some competitive reasons, some just awareness reasons. We started to go deep on those populations of closed or payer complete data, and through that process, we understood the sampling bias of a lot of provider-derived systems.
Through that, we started to realize where those opportunities for deeper insight that other folks didn't have were, and then we could parlay that to successfully using that information to build better products.
That started to happen in 2016. And at the same time, we're seeing a lot of copycat companies coming up and saying, "Hey, we can build a better app." That was happening too.
So either I was going to outcompete on the features of my application or I was going to go deeper in the stack and show people that our true strength was in understanding how data and analytics could be linked at scale to create great products. We chose the latter path and that's been good for Komodo. It's not the right decision for everyone, but it's been good for us as a business.
That evolution is super interesting. Even in the business today, you've got this dataset that you'll sell to other folks that are doing applications. I see partnership announcements with you guys all the time, working with other healthcare players. At the same time, you build some of the applications yourself that your end users use. How do you think about, "Okay, we're willing to provide data to someone else building an application," versus, "Hey, if it's medical affairs, we want to own the workflow tool that someone uses there"?
The first distinction we have to make is that we are not reselling the data, which is the best part of our business. We force people to use our platform. That's because we're constantly updating. It's not just the data itself, it's all the APIs that sit on top of that.
For example, we sit on one of the best de-identified patient masters. This sounds like a silly problem. Everyone's going out there tokenizing their data. The number of tokens that I have that are based on first name, last name, date of birth, and gender — this is the process of de-identifying information. I have 650 million of them. You tell me, how many people are in this country? 330. Okay, maybe 10 to 15 million have died. Maybe you've got some medical tourists. I should see 350 million tokens. I see 650. And that's because the information that is captured in healthcare systems is garbage, all over.
So in order for us to standardize all of this, we have to have a great de-identified patient master. Well, that's what we do. That's a service we provide. Then when I'm taking that information, that I'm combining with other features, and I want to say, "Hey, is this patient likely to be one or two identities? Is this a single identity?" That's a service we provide.
All of these things that go into doing this well are what our platform does on top of the data. That's where I think folks are saying, "Maybe I don't need to buy the data. Maybe I can just work with a platform that provides these services because it costs a lot less, it's way more accurate, and they've actually done the work and built successful applications off of it. Maybe I can do the same."
Part of it, for us, is getting to build a whole set of platform services that allow for any sort of labeling of a patient episode, a label of a patient capability, a patient characteristic, that somebody else can benefit from. We provide that platform service.
Now, to the decision of “Do I enter this with an application or do I allow others to build?” Ultimately, platform companies get fully agnostic to the application suite, meaning to truly be a platform company at scale, you don't protect any piece of your territory. You compete with your application side of it.
We're at that point where we have a whole range of consultancies and other folks who build competitive services in life sciences or insurance segments that are building on the Komodo platform, that are providing services that compete with our applications.
Some of our customers want a lot of consulting-heavy services. Great, they can get that, and we still get platform economics. Others are seeing the future and using applications, our applications in particular, and that's great. But we make ourselves a little bit more agnostic to that.
We've adopted the mindset that to drive rapid improvement in healthcare, we have to be open, we have to allow others to build things that compete with ourselves. It's been an interesting transition for us as a business, but one that we've had to adopt to scale like this.
Where do you think about drawing the lines of, "Hey, we're not going to build applications that do X, Y, or Z"? I mention this because I refreshed your product page before we talked. Maybe they've been introduced over some period of time, but I saw that you've got some of these patient-facing applications starting, whether it's CareConnect or the Medical Information Cloud.
I certainly see the extensions to the existing product suite you have, but it also feels like new territory for you guys. So 1) I would love to hear about the decision to go into that, and 2) are there boundaries to places where you're like, "No, we're never going to build applications that look like that, that's for our partners?"
When we think about building an application ourselves, we have to see that the market's there for that application. It has to be robust, it has to be large, it has to be something that we're excited about. We tend to like categories where we already have a footprint — we are already selling to that buyer and this is yet another product that they can add to their portfolio. It's a lot easier than pushing into new areas that are completely greenfield for us. We tend to look at those characteristics when we're making an application buying or building decision versus partnering.
Now, in what you described specifically with Medical Information Cloud and so on, this is an extension of our medical portfolio. What we're seeing is that there's an incredible need for lots of medical information to be going out to customers. So there are definitely concepts where people think about building a lot of content and protecting it in some sort of vault. We think about pushing out content and making it easier for both consumers and healthcare providers (HCPs) to get that content.
Medical Information Cloud is designed with that thesis in mind and it fits within this broader vision we have for medical, which is that we want to make the medical scientific part of the pharmaceutical company really successful in being able to bridge all of these different systems.
There's this incredible plethora of first-party systems that are capturing all kinds of random data. We see the outside world really well. We see unmet needs, we see HCP needs, and we bridge those two worlds with our software suite.
This is a strong area of growth for us as well as a thesis that we have, that the future is in connecting these two worlds and making it easier for consumers and providers to get the information they need. We like to enable systems like that because it's very mission-aligned for us.
Totally. It seems like if the first step of these people's workflow is, "Let me use Komodo data in the platform to identify these needs or identify a publication I might do," you're now extending it to, "Let's take the next action you're going to take. You've used Komodo to do research, why not publish it? Or you've used Komodo to figure out a need, why not then contact the healthcare provider or patient?” It makes a tremendous amount of sense.
One thing I was struck by in your telling of the story of how you got to founding Komodo is it sounds like when you were at McKinsey you were doing some medical affairs work. I'd like to think that you saw one too many consulting project working with this data and you were like, "There should probably be some sort of product here."
I'm a former consultant so it resonates. As you think about the set of things that consultancies do today, are there opportunities for more Komodos to bloom in terms of taking things that these firms are doing and productizing them in some way?
A hundred percent. I think the best ideas that entrepreneurs develop are born from their own experiences. And it's because we all, as consumers or as folks who work, have an observation. Every time a commercial brand asked a question, I would literally run the same Excel sheet against it. Who are the top prescribers or who are the top KOLs or where in the community are you seeing these patients? It's the same thing over and over again.
So our thesis was, "We could take 80% of these questions that are being asked over and over again and standardize them through a set of reproducible algorithms that give you really great answers that are disease and context specific." You have to think about how you abstract a consulting question into something that's reproducible. For us, there's this notion of “Create the cohort; find the cohort of patients.” Then, it's “Express it through the healthcare system,” and then it's “Model whatever vector you're looking for.”
It's a simple multi-step process, but one that's definable. You can take that into any problem you're solving, anything you're consulting for, inside or outside of healthcare. Just think about how you would create a process around a question that gets asked, and can you then productize that through software, through data, through a better experience?
To me, that feels like a huge opportunity. A lot of these consultancies are trying to become tech companies, but they realize that they don't know how to create software that lasts for five years. They know how to build software one-off. So it continues to perpetuate this “build custom thing” model. Whereas I think SaaS companies or companies that are building enterprise software take the mindset of, "How do I do this once and push it to everyone and then teach people that this is a better way?"
I think that if you can get to that level of abstraction from whatever problem you're in, you will find that there are tons of categories that can take a person out of the loop and instead use a machine, use automation to make that happen.
It's interesting that it seems to have come full circle now, where these consultancies are using your product and maybe just evolving the engagements they're doing or doing a next level on top. So you improved the overall quality of these engagements too.
Yeah. And in our world as well, these legacy aggregators have this third-party agreement mindset, which is, "I'm going to enforce a very narrow set of rights that these consultancies can have." It's this very adversarial relationship because they're taking consulting away.
What's special about Komodo is we don't have an army of consultants. We don't care to compete as a consultant. We want folks using our platform. We think it's the best platform. We think you get better answers. You can have a better experience. My job is to encourage every consultancy out there to use it as a partner.
That, to me, is a different mindset and it requires a certain belief that the market is not going to just change and adopt Komodo software tomorrow, it's going to require a lot of folks to get behind a vision that I think scales in the future.
It's a good point. Another way to build a business like this is to take the data, put it in a walled garden, and just allow your services to be sold on top of it, which obviously other folks in the ecosystem do. I think the openness makes a ton of sense.
I want to move on to the quickfire round because it's always a fun part. To start things off we often ask people: What's one thing that's overhyped and one thing that's correctly hyped in digital health? For you, I'd like to do a more specific version. People are always talking about new data sources and saying, "We can do these amazing things with all these things that are available."
As you think about data sources and how they're used today in healthcare, what's one that you think is a little overhyped for how useful it is right now and one that's correctly hyped?
I'm going to say the unpopular thing, which is for the last six years, EHRs — unstructured notes — are the most overhyped piece of information. There is nothing that you are going to get from unstructured notes that's going to dramatically change the outcome of your study, of your work. Yet everyone is enamored by this idea that some companies possess this crazy advantage of having unstructured notes.
On the other hand, what's correctly hyped is the value of lab outcomes, whether that's genomics, genetic studies, or a simple BUN creatinine. For us, those results, which used to be in the unstructured notes, are fundamental to sorting out the differences between phenotypic and genotypic characteristics of patients.
If I'm trying to model a rare disease, having true gene-positive patients and knowing that against a gene-negative patient cohort is essential. I think that, in the right hands, the AI and ML you can do on that is incredible. I believe very strongly that as more and more lab result data gets made available to be used in de-identified analytics, the fidelity of models accelerates dramatically. And I think that, for a lot of conditions, means a lot more than what we can abstract from an EHR.
What are people getting wrong on the unstructured notes? Is it just that there's not the data they want in there, or is it too hard to pull out any data from there in a statistically meaningful way?
We don't care about opinion as much as we do fact. I want to parse images. I want to parse video. I want to parse lab results. I can now get access to that directly. I don't need a provider's interpretation of that. I don't need them to write 50 symptoms down on a piece of paper. I can abstract that from a device.
The reality is that so much more information is in the endpoint device or the endpoint machine that's being used to generate it. And that is digital native. So I don't need to wait for some really bad EHR to bring that data in across their APIs and structure it in some way.
I can skip the EHR. I can go directly to the source of that generation, that machine, that device, that company, and I can abstract it from there. That's the fundamental shift that we're seeing happen in the market right now. And it's great because it reduces the power of a legacy EHR from controlling information and it puts the power in the hands of the generator of that information.
We've seen that with innovative EEG devices to next gen sequencing devices and machines that can have the data digital native in your hands five minutes after it's run. To me, that is the fundamental future that we're operating in, which is going right to the device generating the information.
That makes a lot of sense. You've probably learned lots of lessons since starting Komodo. If you could go back in time and tell yourself something in the beginning, what's one thing you wish you'd known starting out?
I think we touched on something that matters a lot to me. If I knew that we would be such a profound platform for performing de-identified analytics to scale, I would've built that. I built all my applications off of my platform to begin with.
We were like, "We just need to build our app, get out there, get our first sales." We were acting like every other entrepreneur. We weren't taking that 5- to 10-year frame at the time because we were focused on survival.
I think the benefit of having gotten to our stage is that we see the market through a dramatically different lens. As much as I used to rail on businesses that would go build this thing that nobody would use, I now think that I would've been better off doing that at the beginning.
That being said, we only have the right to do this now because we proved that our applications make sense and create a ton of value. I'd like to think that is something I'd go back and change, but at the same time, we did learn a ton by going out first.
Super interesting. You were an MPA before. If you had a magic wand, what's one policy change you'd make to improve healthcare in the US?
We've all seen the way that COVID changed the level of data sharing between public and private institutions. I think it's fascinating. We had daily reports of cases that were all being submitted by everyone, validation of that. Then as we moved into the vaccines, you see this incredible parsing of very specific injection, specific vaccine, and specific age groups. The coding is perfect in this space.
The observation I have is that if we could treat every public health crisis, from cardiovascular disease to cancer, the way we treat COVID, the ability to impact patient outcomes would be enormous.
If I were to wave a magic wand from a policy standpoint, it would be to impose the same level of reporting standards, fidelity, data collection and data sharing to every other condition as what we saw with COVID, for the benefit of public health. I think that is a huge opportunity to improve public health in this country, and if I were a policy maker, I'd be focused on that aggressively.
It's a super interesting point. You guys helped with a lot of that COVID research, so you’ve seen firsthand the impact of using that data.
Absolutely.
We’ve talked for a while and I'm sure people will be intrigued to learn more. Where's the best place for them to learn more about the work you're doing?
You can find us on our website or on LinkedIn, but there are over 800 dragons around the world, reach out to any of us. We're so passionate about studying healthcare costs and outcomes and helping improve them through better data and insights and analytics. So just reach out to any of us. You'll find someone who's passionate and hungry to learn what you're thinking about and see if we can help you.