Brendan Keeler, Senior PM at Zus Health, on building infrastructure for digital health

Permalink

Can you talk about how you reach initial product market fit and give us any sort of milestones as to where you are tracking towards that?

Zus is a little unique in that we have this heavily experienced executive team, Jonathan Bush and others, that have a unique draw. So, we were able to foster, both because of that star power but also because of the promise of what we're building, a really strong early access community. Those 40 to 50 digital health builders have been really vital to iterate and find and build the right things. The lines of communication - I've never been in a place where we've been as tight and as easy as it has been with this early access community, and that's allowed us to really go through, and, just like any startup, make some misses but really recover fast and continue on. As for milestones, I think we have that early access community. They're not only using the Zus product, but they're all heavily engaged and want to use either products we've developed or will develop.

We're in the process right now of onboarding a number of the first of the first, those zero-to-one customers, and that's really exciting. There are unique stresses as you go to production with any customer.

Can you give us a taxonomy on the digital health space and help explain the differences between software, provider organizations, and then patient apps?

Like I mentioned earlier, five years ago, if I was making a digital health tool, it was a scheduling app that would sell to Sutter Health or University of Pennsylvania, or these edge software pieces that are business associates of these covered entities. I think, fueled by the pandemic, fueled by a number of different societal trends, we're seeing virtual become a very viable paradigm and one that is superior, in many ways, to traditional health systems. However, traditional health systems largely are, as incumbents but also by nature of how they've evolved, not really able to take advantage of it natively and foundationally. So, digital health provider organizations, which five years ago, were shunned because “it's services”, “it's operationally heavy and not SaaS”, are now becoming increasingly viable and interesting to investors.

Those digital provider organizations, you see things more like, again, Omada, Teladoc, etc. You see Spora Health. There's a new one every day. There's no shortage of talking to these groups, and they're really exciting because not only can you segment them by disease or by the group that they serve but also by their go-to-market. They could be direct-to-consumer. They could be B2B2C or B2C2B. They could be going to employers or payers. They could be going and trying to get in-network.

There's just a million varieties of these under the sun, especially in the way that the market has been lately with funding. Perhaps that changes if the market changes. And then, lastly, there's wellness apps, things that fall outside of HIPAA that are not covered entities, from Peloton, which is health and wellness, to a personal health record like a OneRecord or something, and those have increasing viability because of a regulatory change that is enabling them to have really powerful channels to access data in ways that just weren't even thinkable or possible a couple of years ago. The jury is still out to say, "Well, who adopts a personal health record? How do you monetize a personal health record? How much?" 

In that space, I typically like the wellness apps a bit more. People who want to be fit are going to go and use a Peloton or something, or people that want to measure their blood glucose, or whatever, can use Levels (or whatever that one is) versus, "Let me just aggregate the data." Does it yet have full utility, or has it fully been productized in a way? But I think it will be as, increasingly, they're able to do more and more.

Permalink

Can you talk about virtual health in general? Why was that the first big area of focus for you all, and why is it the right place to get started and be increasingly important in the future?

We think these virtual health versus health providers are going to continue to grow, and we're going to see more and more of them. They're going to take up disrupting a lot of the old way of doing healthcare. So, growing with that growth and servicing the needs of upstarts, of the renegades, those who are underserved in a way that... Traditional EHRs can do the job for Sutter or Dr. Smith, who is on Athena or whatever it might be, but these digital health providers want to build something really special and to bring a lot of tech talent that has experience in really modern, slick, frictionless consumer experiences, and you try and bring that to bear on when you have an EHR that has a MyChart patient portal, it's just not the same. You can't even get close, so you need Zus, and there's a lot of other companies popping up that are helping in different ways for the same class of customers. Ribbon Health is another API company that is very, very, very powerful for this class of customer. I think that just like Stripe wants to grow the GDP of the internet and help people do that, we want to grow this class of customers so that they can help their patients and that we can give them the tools to really build what they want to build.

Can you talk about the history of digital healthcare and healthcare APIs, where Zus fits in there, and what's different about the new FHIR standards as opposed to its predecessor? And what problems does FHIR solve for startups building in a health space, digital health space?

Historically, software and healthcare (“health tech”), the less sexy version is dominated by electronic health records. These electronic health records started in the 70s, and Epic was ’79, Cerner was probably in the 80s or something. And they needed ways to communicate, so they made a standard, and this standard is HL7 version 2, and it's ancient. It's not a modern, internet native way of communicating data. It's not built in a way that is easy to learn or onboard or that a developer can pick up and run with. So it did the job well enough for a hospital to buy their EHR and then connect some systems, but it's just a slow, gross multi-week, eight weeks, 10 weeks, months to just get an application and a doctor and their healthcare organization who want it to be deployed to get it integrated in.

APIs are now dominant across all industries as a way for developers to engage. The HL7 community said, "Hey, we want to ride this. We want to have that same experience but in healthcare, and to do so, we need something new." So, FHIR, the Fast Healthcare Interoperability Resources, is the standard. It's a JSON API standard that is a collaborative effort by competitors to come to a consensus and say, "This is the API that the EHRs will build." And so that makes it even easier for a developer to go and say, "I'm going to develop once and then hopefully scale that across many, many vendors." And whether it's FHIR or just the API economy, the promise of this for people - developers, product people that work in tech - that come to certain expectations around how to develop are now met, or hopefully met, by the FHIR standard.

FHIR is still not fully implemented by all the electronic health records, but compared to five years ago or 10 years ago when I started in healthcare, it's night and day, and the ability to perhaps, at least sometimes, have a modern development experience and a modern way of being able to deploy applications and get value into the hands of customers faster, it's leveled up tremendously. And I think they'll only continue to grow because of that experience being positive but also because the government is saying that people have to do it.

There're various companies in the healthcare interoperability space like Lineate, Redox, Kno2, Particle Health, and Health Gorilla. Can you help us better understand this market, where these different players stand, where does Zus fit in, and do you think about Zus being competitive with any of these companies?

It depends on the time range. A long enough time horizon, we're competitive with everybody, but to start, I don't see it as competitive. I think there are some pieces of our product offering that are quickly, in the industry, becoming commonplace commodities. So, this data access I'm talking about, as these historical silos and walls are being knocked down, means that data access is easier than ever. So, Zus having that offering of pulling in data is, I think, table stakes. It isn't necessarily a differentiator for those that have said, "Hey," like a Particle or Health Gorilla, they may say that's their key offering, and they don't see it as table stakes, but I think they perhaps might be missing something if that's the case. 

The way I would segment this interoperability market is that they seem similar, but it's almost like Plaid and Stripe. Both are in fintech, but they serve very different needs. The equivalent of Plaid in healthcare is consumer authenticated pulling of data. We have a Human API. We have OneRecord. We have 1up. They all do that same function of, "I'm a patient. Let me log in. I can pull data, my data from a patient portal." That is similar to Plaid. There're clear parallels. That serves primarily the needs of those consumer apps and non-HIPAA entities. If I'm life insurance and I need to pull health data to underwrite somebody, this is a viable mechanism to have the patient log in and pull their data.

That's that set of consumer authenticated API companies. Then there's Redox and Lyniate. I'm trying to think of who else… NexHealth is a popular one because Packy wrote about them recently. This group all serves the business associates. Suppose I make software. I sell to hospitals. I need to scale that as I sell it to 60, 70, 80 hospitals. They serve to make it easier. They're just tools to allow you to plug in once, and then it's easy to connect to many hospitals for those very workflow-intensive integrations. So, they're network builders. I think a parallel in another industry would be a Modern Treasury in fintech or something like that, where you're not using consumer authentication. You're not overlaying a preexisting network. 

The last class of API company or integration company in healthcare are the people that just overlay old networks that use old standards that have a non-modern API experience. They're doing a Stripe essentially. Stripe has no network of itself, at least for their core product. They only have the credit card networks that are ancient transactions, and then they say, "Don't worry about that. I'll take away that pain. I'll use the knowledge I built by doing this a lot to give you fraud detection and value adds that you otherwise wouldn't have, and here is an easy API”. So, Particle, Health Gorilla, Kno2, there's a lot of these guys. They all offer that same promise for different legacy networks. They primarily sell to digital health provider organizations. So, competitive in the sense that they own some of the mind share that we probably want, but not competitive in the sense that they don't have the same product, vision, roadmap, and feature set that we do. We're not building the same thing as them, but certainly, they're selling to the same customer types.

Some big tech companies have taken aim at digital health in the last few years between various alphabet subsidiaries to Amazon with their new care product. How do you think about the opportunities and difficulties that these kinds of tech incumbents will have getting into healthcare?

There's this popular narrative of, "Big tech can't do it. They can't get into healthcare." I think that's kind of BS. Every company has their successes and failures, and if they stick to core competencies, they can make an impact. They're not going to come in and revolutionize things, but I think of Amazon. Amazon is very good at reducing the friction of a good or service from getting to me. "Good" could be them shipping me a book, or it could be them shipping me the medications that I need, or it even could, in the future, be them shipping me the phlebotomist to take the blood for me. You could think of Amazon Prime for healthcare, which is essentially their Amazon Care product. I think that fits their core competencies and fits their mission of taking a slice, a little percentage of every human interaction or purchase.

I think where things get trickier is when the big tech giants do something outside of core competency. You saw Apple, a couple of years ago, try and spin up clinics and be a digital health provider. I don't think that fits their core competency of a hardware consumer mindset. It's a very operationally intensive thing. When you see they've got out of that business and now do Apple Health, which is on your iPhone, you can pull your records via that patient authentication that I mentioned. That fits them. And so, for big tech, they have a lot of resources. They have some really smart people. Obviously, on the infrastructure side, AWS, Google, and Microsoft are going to have some impact by virtue of cloud tooling. Beyond that, these more specific offerings they go after, as long as it fits their core competencies, I think they'll find success, and they'll make an impact.

Given their demands on time to train up on new software and healthcare-specific requirements around compliance, how do healthcare providers make decisions about external software vendors? What are the most important characteristics they are looking for?

When it comes to healthcare providers, the big problem for technology adoption within traditional healthcare organizations is that I, as a doctor, am completely disintermediated from making a purchasing decision. Because of HIPAA, because of the compliance aspect, you need to go through a lot... I could say, "Hey, I want this tool." It gets thrown over to the IT team. They do intense security reviews. They have a huge backlog of projects because integration takes so long, historically. 

It means that it's an absolute slog to get any technology, to even just something to play with like, "This might be interesting. This might help me. I could do my job better." I can go do that. I'm not a doctor. But I can do that in my company really easily. I can be like, "This is a cool SaaS. I'm going to try it." You can't do that in healthcare. 

There's some business waiting to be built to help facilitate the business associate agreements and the security. Not just HIPAA compliance as a service -- there's a couple of players who do that -- but selling some sort of software to a hospital to help them programmatically manage the applications that there are out there, and say, "Dr. Smith wants this. Let's get this through the approval process in a programmatic fashion," rather than a big Excel document of like, "Do you host on-premise?" So, traditional security questionnaires, that process, if someone can speed that up from weeks or months and bring it down to days, then that's the hospital that’s going to be really successful with technology adoption, to really accelerate how they deliver care.

Permalink

Given the growth in new startups in healthcare, some startups have kind of shifted from selling primarily to legacy providers -- you mentioned the Sutters of the world -- to selling to other digital health companies. What are the biggest pain points that startups are running into as buy and as they build and sell products for this market?

If you're selling to traditional health systems, if you're selling to payers, because of HIPAA and the way that it makes them think about technology adoption because of the HL7 standards and other things that slow your deployment, so many startups just wither on the vine because they build something cool. Doctors want it, and then they can't get it to be integrated. Or even before the integration, they can't get it through all of the hoops they have to jump to get approval from the administrators of the hospital. Somebody was saying that the average CTO of a hospital sees something like 30 or 40 in new technology inbounds a week in a big hospital system, so they're flooded and unable to process everything that they need to do. Good hospitals / integrated delivery networks prioritize effectively and can get things through faster, but it's still not the same as the speed of a startup.

When I was at Redox, we saw so many of our customers just not be able to get through to customers who wanted to buy their software because of the lethargic pain of months of security and contracting.

The problem does happen whenever you sell into large enterprises regardless of healthcare or not. I'm definitely cognizant of that, but the intricacies of the healthcare ecosystem just accentuate that and make it just double or triple, and that's why there're people like, "I'm going to go back to selling just enterprise SaaS instead of healthcare because to watch something die, a really good idea that could make an impact and save lives or help physicians be happy at a time when burnout is higher than ever, it just sucks. It's a shitty feeling.

Permalink

Where in the future do you see the most growth? Do you see disease-specific virtual care really taking off? Do you see Teledoc or one-stop shop type experiences for customers or for patients? Do you see a more centralized or decentralized approach to medicine for the individual?

As you look at these different virtual first care startups and how they're emerging, there's definitely a trend of mergers across specialties. There's some pain in there because it looks like, "Wow. They do this specialty." Teladoc and Livongo. Livongo does diabetes. Teledoc does the general care. The combined forces are unstoppable, but merging your tech stack is painful. Bringing together different corporate cultures is painful. So, some of this direct acquisition and merging across specialties isn't as effective. I don't know if everyone does their tech due diligence enough to understand there's a significant opportunity cost and pain to making that choice, and there's definitely upside of a large and multi-specialty virtual care clinic, but that's not always the way, an easy path to success.

I like acquisitions that are a little bit more orthogonal to one another. Oak Street acquired RubiconMD. Oak Street does value-based care and is a digital health provider. Rubicon is a software for e-consults. So, they don't conflict with each other as much and definitely not in a tech stack way. They can continue to be run as complementary businesses. That, to me, is a way -- not smarter, I don't think that first one wasn't smart – but there's an easier path to success. And similarly, Roman has been pretty good. They've done some horizontal acquisition just when acquiring the next specialty, but they're also making plays as an infrastructure provider. So, that diversification of go-to market and products is attractive to me. I think that starts to add up and provide some significant benefits.

Many of the new wave of digital health startups are getting traction with specific communities like Dorsata for maternity care, Cityblock for primary care, for Medicaid patients, Firefly for the employee-sponsored market. What do the big growth opportunities look like for these kinds of companies, continuing to drive value in those verticals or expanding horizontally?

It gets to what we were just talking about, but I don't think there's one path to success. And I think, certainly, expanding and acquiring other specialties and being a one-stop shop is an appealing endgame. It's just challenging from a technical perspective. I think smart, orthogonal acquisitions that complement the core offering are a more unique acquisition strategy and growth strategy. In terms of sales, I think payers are now inundated with all these virtual-first care providers coming in, saying, "I want to be on a benefit under your Aetna plans," and they don't know how to prioritize them. So, what's actually becoming increasingly attractive -- a friend named Chris Hogg wrote an article recently about it -- is actually just going back to getting it covered in traditional coverage. Rather than it being a unique benefit that the employer or the plan offers, you just say, "I'm going to go get coverage with different provider networks, and then it's just me hustling and getting in my ground game to get patients to come to my services."

It's more traditional. It allows you to be more marketing, to the customer or to the patient, and saying, "Come here, come here. I'm covered by your insurance," versus these really long, shitty sales cycles with payers that are, again, increasingly getting overloaded in a way that they hadn't been five years ago. Those are different go-to-market muscles. And if you think that you have a great sales team that can sell the big, slow enterprises, and you're up for that challenge, have at it. But otherwise, especially if you have consumer-oriented DNA in your founding team or your scaling team, then getting in coverage, getting your virtual-first care practice in coverage with different payer networks, and then just hustling to appeal to patients is maybe an easier equation.

Permalink

You said earlier, "On a long enough time horizon, everyone can look like a competitor." Today, you're focused on virtual care. Do you see that changing for Zus in the future ever?

Yeah, I think at some point. There's a million potentialities out there where we might go. We may just say, "Hey, we want to complete this headless EHR via an electronic health record that is fully API enabled." That's one possibility, and that allows us to sell to these digital health builders but then really sell to a lot of other players. We might say, "Hey, we're actually the platform, and we want EHRs to come and build on Zus and then sell into traditional markets --  sell them back to the dermatologists or the direct primary care or the psychedelics therapeutics providers. There are a million new niches... There are some really cool, exciting EHRsk. It could be that's how we go back. But at some point, we want the traditional providers to look at Zus and say, "Wow. The experience that these providers are having, collaborating, and doing care on the Zus platform is a level up over what I'm doing. I need to get involved, and I want to go and play in that ecosystem."

Our CEO and founder Jonathan says he "wants them to have FOMO at some point," where they're like, "I need to get back on Zus." So, we'll absolutely have to go back to traditional providers at some point. We'll absolutely want to see how we can get payers involved in the ecosystem. We want to see how we can get pharma to play, but those are all problems to be figured out after getting our community really, really successful. That's the key. The critical path is to have, if the experience isn't this level-up over the traditional one we have today, then there's no FOMO, and so then we don't have to worry about them.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.