a16z Podcast - 16 Minutes on the News #6: Health Claims, Corporate Breaches

Episode Date: August 12, 2019

with @julesyoo @smc90 This is episode #6 of our new show, 16 Minutes, where we quickly cover recent headlines of the week, the a16z way -- why they're in the news; why they matter from our vantage point in tech -- and share our experts' views on these trends as well. This week we cover, with the following a16z experts: health claims, insurance & big tech, and healthcare data liquidity -- with a16z bio partner Julie Yoo; Capital One data breach, cloud security, and corporate hacks -- with a16z operating partner for security Joel de la Garza; ...hosted by Sonal Chokshi.

Hi everyone. Welcome to the A6 and Z podcast. I'm Sonal and this is our sixth episode of 16 minutes, our new news show, where we cover recent headlines of the week, the A6 and Z way, why they're in the news, why they matter from our vantage point in tech, and share our experts views on the trends involved as well. You can catch up on past episodes at A6NZ.com slash 16 minutes or subscribe to it as a separate feed in your favorite podcast player app. This week we have two episodes since we'll be skipping next week. This episode covers two other topics that came up. recently. The Capital One breach, is it more of the same or different? How does it fit into the seemingly endless string of corporate hacks? But first, we dive deeper into recent news around health care claims data and insurance providers, which sounds boring, but is apparently not. Okay, so the first segment is on recent news that a number of big tech companies, including Amazon, Apple, Google, and Microsoft are working with insurance companies in order to help provide claims data to patients. And this came about at a developer. conference hosted by a coalition called this Karen Alliance, which is basically a bipartisan

multi-sector collaborative. That's what they call themselves. And it includes a lot of former national health coordinators, the U.S. first health information technologies are, the U.S.'s first CTO, the former Secretary of Health and Human Services, and a number of other people are working in this alliance. But the key point of this, and just to summarize the news before I introduce our A6 and C expert, is it's the first time that health care providers are giving claims data to third-party developers. So just to summarize also some of the stats around claims data,

so apparently there are 4 billion prescription claims and 3 billion medical claims processed every year. And then in terms of the cost of the health care industry, $315 billion is spent on health care claims, of which 35% is administrative waste or overhead. So now I'm going to introduce our A6 and Z expert, Julie Yu, who is a former founder of a patient provider, matching startup and is a deal partner on the A6 and Z bioteam who is focused on all things care

delivery. Welcome, Julie. Great to be here. I'm so excited to hear from you because honestly, claims it is the most boring effing epic on the planet. Honestly. And I think it's very sexy. You do because it was a why. Tell me why it matters. At a higher level, the notion of data liquidity in healthcare, and it's almost an inevitability that it will eventually occur. But to see things like this is very exciting just because it's making it all real. When we think about the consumer angle, you know, oftentimes what you hear from consumers with regards to health care is it's inconvenient, it's slow, and I never know what's going on, and it's opaque, and I never understand what things cost and transparency. And I think claims data

specifically has a role to play in making all of that better. Why is that? Like, what is it about claims data, specifically? Because when I think of claims data, I think I have so many bills outstanding and late fees from labs, because, like, I go to the doctor's office and the lab is a separate office, and they have two different billing systems, and then I'm like, what the heck? Yeah, exactly. So in very simple terms, claims are basically the invoices of healthcare. It's the equivalent of if you were to go to a mechanic and get something done to your car, you'd get a list of the things that were done, how much they cost, etc. Now, there are many different types of claims data. You mentioned lab data. There's, you know, medical claims data. So services rendered by a physician or a nurse. Like in an office. Exactly. Office visits, hospital visits. There are prescription claims claims data. So drugs that are prescribed to you, those can also be claims-based payments. And then there's many different elements of claims data that we should be aware of. You know, one is that claims because they take so long to process can be in very different states. And depending on when you see a claim, you might see very, very different information.

What do you mean about that, like specifically? Yeah. So the average length of time that it takes to fully process a claim can be anywhere from two to three months, upwards of many, many months beyond that. And the reason for that is that, you know, the process involves, first of all, a provider submitting a claim to an insurance company saying, here is what was done to this patient. for these specific line item services, and here's what I think I should be paid.

The insurance company then receives it, and by the way, that process of just simply receiving it could take weeks because there's lots of middlemen. It could be a paper-based process, et cetera. And so then the insurance company finally receives it. And then ultimately, they need to adjudicate it. They need to determine whether or not this was a valid service per the contracts, per the benefit of the consumer,

and therefore how much am I actually going to pay, and then how much am I going to leave to be paid out of the pocket of the patient. And so that end-to-end process is, very lengthy, involves many multiple players, intermediaries, and depending on when you see that claim in that entire cycle, as you can imagine, you might see very different information. So is it pre-adjudicated versus post-adjudicated? Is it sort of coming from the provider side? Is it on the insurance side, et cetera? So for instance, one of the major things that insurance companies have been very reticent around sharing is the full set of a loud amount data.

And what that means is basically when a physician submits a claim, they will put their sort of billed amount. But contractually, they may have specific rates that are negotiated with the insurance companies. And releasing that into the public would obviously negate any negotiating leverage that they might have with providers in certain markets. That's so helpful. I love the lay of the land, the context for how the claims work, the process. So now, back to the news. Why does it matter that developers can develop on top of this? Like, it sounds like a very complicated system.

People don't have incentives to share, be transparent. Like, there's already enough middleman. What does it help to have third-pright developers in the middle here now? Yeah. Well, I think ultimately the beneficiary will be patience because these companies will ultimately be developing apps that are consumer-facing. And I think we can probably break down the benefits into two major buckets. One benefit is simply financial transparency.

You can imagine, like, a mint.com of health care finally being built. There's actually, unfortunately, sort of a graveyard of companies that have tried to do that in the past. some of the challenges that those companies have faced are around, you know, the lack of liquidity of data. It's funny that it's a novel thing that, you know, all of a sudden the insurance companies are going to sort of buy into making APIs available to consumers because that data has existed in a B2B format for other companies. So the consumer thing is actually the real new thing because that patients can benefit

through those apps. There are actually multi-billion dollar businesses made on using claims data for other commercial purposes. One example that probably not so many people outside of the industry know about is claims data are actually used very heavily by pharmaceutical and life sciences companies. And the use case there is, you know, taking sort of the claims exhaust from insurance companies. The data exhaust, right? Yep.

And using that to inform which providers see what types of patient populations. And that can be informative to everything from clinical trial recruiting, who are the physicians who are most likely to have patients where they can be recommended certain alternative therapies. And so that is a very robust industry that's existed for decades. And that is actually a very liquid use of claims data. And what's the other bucket? The other bucket is actually the health benefit.

From claims? Well, this is the Holy Grail. And I think one of the interesting things about this announcement, it might be nice to have that information, you know, just an ability to see what was done. But really, the Holy Grail is how can I move the needle on my health status? A lot of companies have also tried to use claims to make health claims. You're kind of unintended there, but there's only so much you can see in a claim that can then imply what actually happened from a health care perspective.

Right. So it's the equivalent of trying to infer, you know, how did the food taste based on seeing a restaurant receipt. So that's really where the need for medical record data becomes very necessary, right? The actual clinical context around a given claim can tell you a lot more about the health status and therefore what you can do to move the needle on that. If you compare claims to medical records, claims are sort of the broad data that will give you a full, much more comprehensive set of information about what has happened to you. Whereas the medical record and the other types of data we described are sort of the depth. So you get the breadth versus the depth as a baseline. Right. You can provide sort of a scaffold, let's call it, of the journey that a patient has had around their health condition as a starting point, which can then inform, okay, it looks like I should double click here and understand what happened around this particular event.

So bottom line it for me. How should we think about this news in the broader context of healthcare and in particular where claims really fit in? Yeah, I think we should be very optimistic that this is yet another sign that data liquidity will be a basic piece of infrastructure within our industry. That said, I think this is only step one of many steps to come around really getting a holistic understanding at the consumer level about what's going on with your health care. So if claims is like V1.0 of data liquidity, you know, medical, actual medical records can be V2.O. But really what I'm excited about and what I think the whole industry is looking towards is the V.3.0, which would be all of the sort of non-medical but health related content that actually can matter to us as consumers that we can control and use to drive our health outcomes. So it's things like food. What is my social status? We're now recognizing more and more that things like social isolation are huge contributors to negative effects on mental health.

And even things like GI issues have a huge mental health component. And so literally understanding what my social interactions are, I could have a huge impact on that. Well, thank you for joining this segment. Thank you so much, Sonal. Okay. So the last segment this week covers the Capital One data breach and how corporate hacks happen. So let me quickly first summarize the news. First of all, Capital One is a financial services company, and they do lots of things, including provide credit cards.

They're considered one of the 10 largest banks in terms of assets, and they are the third largest credit card issuer. And credit powers a lot of our financial system today. So what someone stealing that data is not so good. So what someone did is a hacked into a server holding the personal records of over 100 million people, and here's what they stole. 140,000 social security numbers, 80,000 bank account numbers, 106 million credit card applications from between 2015 to 2019, according to the company. It's one of the largest data thefts from a bank ever. It's estimated cost right now is about $150 million, just for context compared to the Equifax Credit Bureau breach of 2017. That one exposed a sensitive information on over 147 million consumers, and it costs way more about $650 million.

And they just settled claims for that about two weeks ago. So that's a quick context for the news. Let me introduce our A6 and Z expert, Joel De LaGarza, who is our operating partner for security, was a former CSO chief security officer at Box. He's actually investigated a lot of breaches. He was responsible for incident response for Deutsche Bank and Citigroup. And in his career, he has worked on over 100,000 security incidents. Welcome, Joel. Thank you.

It's good to be here. So, you know, there's a lot of data breaches. So I almost felt like, why are we even doing this as a news item? It feels like it's the same old story over and over again. What is different or unusual, if anything, about this one? Well, the interesting thing about this one is that Capital One has long been kind of the most, one of the most sophisticated, most secure adopters of cloud technology. I think they were probably the first large financial service to actually move to using cloud services.

They really leaned into a lot of these technology trends, and they've transformed the way that they build and roll out their business. And so for someone who is so sophisticated to have a breach of this magnitude happen to them on their new platform is actually quite a stutter. And what actually happened just in the details is that apparently the hacker got in, it was a 33-year-old hacker from Seattle, a software engineer. She got in through a firewall misconfiguration, and they themselves are speaking of them being a leader in cloud,

services are on AWS, Amazon Web Services. But apparently the underlying cloud services were not compromised. Can you give us some more details on how the hack happened? Well, I think that the indictments that were released by the U.S. government were fairly detailed, but they don't provide all of the kind of relevant points. And there's been a lot of speculation about what the underlying causes are. And folks are trying to make this sound similar to a lot of breaches and a lot of other kind of scenarios that impacted other companies. And so I think people are filling in the blanks and we still don't really know the details. But at a high level, it sounds like there were some pretty sharp edges in the way that this cloud service provider's

configuration for a product worked, and the configuration was not set appropriately. And so that allowed for an issue where internal services could be exploit, data could be exfiltrated. It's a fairly common occurrence that's happened to a lot of companies this year. You said that it's actually sometimes hard to tell that the information hasn't really come out. And one of the lines I used to love saying, and I continue to say when we talk about hacks, is that attribution is hard.

It's hard to figure out who did it, who done it. Well, it's hard until it isn't, right? I think with this situation, we've got a computer intruder that was bragging about sort of the activity that they had done. And they were engaged in several very prominent hacker chat channels taking credit for their activity. And they actually had posted some of Capital One's data to a publicly available GitHub repository. Another security researcher was out there looking through GitHub repos and found Capital One's data and turned around and reported it to Capital One. Well, the thing that's funny to me, even though it shouldn't be funny. The FBI noticed her activity on

meetup and she posted comments on Twitter and Slack of all places. How does this fit in the overall taxonomy of corporate breaches? We keep hearing about one every year. Target, Equifax, the list goes on and on. So in the old days, when things were predominantly on prem, people were running their own servers, on premises, right? As opposed to software as a service or cloud-based. As opposed to SaaS or cloud or whatever the case may be. In those days, breaches typically happened because software patches weren't applied or someone gave away their username and password. And that was kind of how we got most of the large breaches. Equifax was the result of a software patch

that hadn't been applied that allowed the hackers to get into the network and infiltrate the data. As we've moved to the cloud world, we've gotten out of the need to patch a lot of this stuff, right? Cloud solves a lot of these problems.

The number one source of breaches now seems to be misconfiguration. That's something we've been noticing for the last couple of years. It's actually one of the forecasts that we made earlier this year looking at all the data, that these kinds of configuration issues

will be the things that drive breaches into the future. And why this category of configuration issues, what does that mean? In this case, it was supposedly a firewall misconfiguration. Why wouldn't a cloud service provider just set it all universally for everyone? So they are in the process, and Amazon has made, and Amazon, Google, and Microsoft have made a lot of attempts to make a lot of these tools more easy, intuitive,

and just more rapidly to be deployed. But one of the challenges is when you're a large cloud service provider, you're trying to hit the right balance between safety and security, ease of use, and features, right? And I think what generally happens with security in the cloud world, having come from box and work through a lot of these problems, is that you have to find that balance between ease of use and security. So a high-level understanding of how this breach occurred is that there was some kind of a misconfiguration on a web application firewall provided by a cloud vendor. Now, none of the products are specified, none of the vendors are specified. But there was basically a misconfiguration on a web application firewall that somehow exposed internal resources, right?

resources that were not supposed to be available to the public. And this person found those internal resources, was able to access them from the outside, and then exploit them in such a way that they were able to take more data from them. Right. Isn't that pretty common, if I recall, because I covered the AT&T breach back in 2012. I even edited an op-ed from Weave of all people, but isn't that what he did? Kind of hacked into the AT&T thing. Yeah, this is a fairly common. I mean, the traditional way that you would build these sorts of applications and build this infrastructure

is that you have transitive trust relationships. So it's the idea that I've got this hard perimeter, this really solid firewall and perimeter that keeps people from getting in. And inside that perimeter, it tends to get softer, right? So services are available. Things can talk to each other that you wouldn't want to have happening on the internet.

Which enables collaboration and people to work together. Which enables collaboration, rapid deployment, all sorts of really interesting things. However, the moment you breach that perimeter, you expose these internal services and your data can be exultrated. And so the mood now, and generally in the industry, people are moving towards what's called a zero trust approach,

which is to remove the concept of having this perimeter, remove the concept of a firewall, just assume there's no trust in any environment and build your services according to that kind of a model. But won't that be hard for people wanting to collaborate and balance all the security, usability, convenience that you talked about? I mean, you could argue that actually once you start to build security in, you actually make it a design requirement along with ease of use, along with interoperability, that you can actually make sure that all those requirements are met.

And if you look at really successful software companies now, they start with security built in. Until security's baked in hard, what can companies do to protect themselves? The first is obviously choosing quality vendors, making sure that you appropriately vet your third parties. I think in this specific case, right, how do you prevent these sorts of things from happening?

The fact that so many people were able to infer exactly what happened in this specific breach means that it's been happening out in the community for some time. And this is just to further supports the case that we need to have better collaboration around information security, better collaboration around security breaches, that things like this, that these attack vectors are shared throughout the community and that people can take the appropriate steps to protect themselves. So bottom line it for me, Joel, how should we think about this Capital One breach in the context of all the other breaches and the taxonomy breaches? Well, I think the unfortunate truth is that if something like this can happen to Capital One, who's probably one of the best in the business, it can happen to anyone.

And so we're going to continue to see this kind of an activity. We're going to continue to see these breaches. And we're going to have to really think hard about who we as a people, you know, want to protect our data and want to think about data privacy. Fantastic. Well, thank you for joining this segment.