This episode of Critical Point is the third in a multi-part series on blockchain and its applications in the health insurance space (to listen to Part 1 click here and Part 2 click here).

Transcript

Announcer: This podcast is intended solely for educational purposes and presents information of a general nature. It is not intended to guide or determine any specific individual situation and persons should consult qualified professionals before taking specific action. The views expressed in this podcast are those of the speakers and not those of Milliman.

Anders Larson: Hello, and welcome to Critical Point, brought to you by Milliman. I'm Anders Larson and I'll be your host today. In this episode of Critical Point, we're going to be talking about blockchain. This is the third episode we're doing as part of a series on blockchain and its insurance applications. In the first two episodes, we got into the basics of cryptocurrencies, particularly bitcoin, how the blockchain data structure or technology fits into that, and then we talked about a couple of key concepts, hashing and public key cryptography, on the second episode. But we noticeably stayed away from actual insurance -- or even any other applications other than cryptocurrency. So today we're going to dip our toe into some other real-world applications, and some of the compromises that have been made to make those happen. So I'm here again with Shea Parkes, a principal at Milliman. So good to see you again today, Shea.

Shea Parkes: Good to see you today, too, Anders.

Anders Larson: All right, so let's get started talking about one of the key aspects that we've talked about with blockchain in the past with cryptocurrencies, and that's the concept of this unforgiving identity management. A lot of that was related to the concept of public key cryptography, and the fact that this private key linked to a public key is really the only way to prove you are who you say you are.

Shea Parkes: Yeah, no, in fact there was something that just came out in the news recently that, unfortunately, someone that had been manning a large cryptocurrency exchange passed away suddenly, and had a password on their private key that [they] had never told a soul [about], and so you know, a hundred million dollars of cryptocurrency assets are now just gone-- well, they're not really gone. You can see them there on the blockchain, but nobody will ever access them or transfer them anywhere again. So it's a really unforgiving system.

Anders Larson: So obviously with that type of unforgiving system, you can imagine how in a lot of other walks of life, people are leery of going that far. But there's still a desire to kind of use this blockchain technology and see if there's ways to extract some of the benefits of it without that. So if you're going to avoid that unforgiving identity management, there are some compromises you've got to make. So Shea, what's the big compromise you've got to make if you're not going to have this unforgiving identity management?

Shea Parkes: Well, if you're not going to be unforgiving, that means you're going to have to let someone-- you're going to have to forgive someone for getting their password, or for forgetting their password or losing their password, and you’ve got to let them reset it or change it or things like that. And soon as that happens, that means there's got to be a central authority that is handling those reset passwords, changing passwords, et cetera. And if that central authority can make new passwords for you, that central authority can access any of the data they're storing. It’s not just you that's accessing it. As soon as someone else has the ability to make passwords, well, if somehow someone nefarious was working at that organization, well, they can technically compromise the data. Now having said that, there are a lot of organizations that we all choose to put our trust in. Such as governments. A lot of governments, you know, and central authorities or consulting companies, people choose to put their trust in. And so there's still definitely some room for some of the ideas in the blockchain technology and framework. Especially maybe if that central authority is a government.

Anders Larson: Right. And so just to kind of refresh. It's not just on the blockchain. In a bitcoin world, the-- it's not simply just the private/public key aspect and the unforgiving nature there that's providing this security without a central authority. We also talked about these races that essentially prevent a single actor from hacking the chain. And so there are, without the central authority, there's ways that cryptocurrencies have been able to provide that security. But again--

Shea Parkes: Oh, sure, it's actually more the data-- we call it data immutability. Or make sure that the history is unchanged.

Anders Larson: Right. So that-- in most of these use cases we're talking about here that some of these aspects of bitcoin have been compromised for various reasons. So let's focus-- we want to focus today primarily on a case-- a use case going on in Estonia. Started about three years ago?

Shea Parkes: Oh, maybe even more than that at this point, yeah.

Anders Larson: Where they have started storing some healthcare data-- we'll get into exactly what that data is-- on a blockchain. So Shea, could you talk us through high level what they're doing in Estonia.

Shea Parkes: Yeah, and please do finish the episode because we're going to tell in a minute here that it's not actually sensitive healthcare data on a blockchain. So, yeah, no, Estonia has been sort of a leader, a thought leader in this area. They've been using blockchains for a few different things. And one that we've researched some is health insurance-- or not-- or healthcare, more than health insurance, actually healthcare. They're really using this with their healthcare providers. Their doctors, their clinics, et cetera, that they have worked and set up a blockchain that's continuously running and adding blocks of data, and it's this healthcare blockchain running in Estonia. But what they're storing on it is not actually sensitive patient data. So what gets stored on this blockchain is that, Anders, if you went to the doctor in Estonia, and they worked on your arm from all the time throwing footballs. And they said, "You know, hey, we had to poke it a few times to make it work again"-- well, they would open up a file on their computer and they'd write down, "Oh, you're Anders Larson. Your shoulder was hurting. I poked it." And then they take that and they hash that text file, which is what we talked about in the last episode. And they send that hash off to the government, and the government puts that hash on the blockchain. So, in theory, there's this long blockchain that nowhere on there does it say, "Anders Larson." In fact, all it keeps on there is what doctor's office. You know, it just says, "This doctor’s office did something on this day, and here's the hash of what they did."

Anders Larson: Okay, so what do I do with this hash? You know, as we talked about in the last episode, the result of something going through a hash function is a number, and it can't be reversed. So I can't take that number and figure out what was done. What can I do with this?

Shea Parkes: So the use case in Estonia is that, "Okay, so Anders comes back here to lovely Indiana, and then a few years later, goes back and visits Estonia again. And his shoulder starts acting up again in Estonia. And he goes to a different doctor. And you know, the doctor says, "Oh, you know, your shoulder's hurting. Have you seen anyone about this?" And he's like, "Oh, yeah, well, I saw a doctor a few years ago, and they poked my shoulder." And they're like, "Oh, really? They poked your shoulder? Okay, let me go pull up the records here." And you know, say, "Okay, well, who was it? Which doctor was it? And about when did it happen?" And this new doctor will first directly contact the old doctor based on what Anders says. You know, call up the office of the other one and say, "Well, did you do anything with Anders?" And they won't look at the government blockchain at the old office. They'll say, "No, I'm going to go look at my EMR, and I'm going to look up Anders," and they'll say, "Yeah, look. I did do something with that. Would you like me to send over my record of where exactly I poked Anders' shoulder?" And the new doctor goes, "Yeah, why don't you go ahead and send over the record of where you poked Anders' shoulder." And they send it securely. Again, no blockchain involved at this point. And they send it over, and the new doctor now has that text file that says, "Oh, well, Anders Larson came in on this date. He had a bad shoulder, I poked it here." And the new doctor goes, "Well, you know, let me just-- for peace of mind, I actually have a way now to confirm that this is at least what the old doctors said they did at the time they did it. So I'm going to take this text file describing what happened, and I'm going to hash it with the same hashing algorithm, and then I have a copy of this government-controlled blockchain right here." And it goes back in history, and you say this happened three years ago, right?

Anders Larson: Right, yeah.

Shea Parkes: So the new doctor takes this text file that says what happens and they compute-- they run the hashing algorithm, and so they compute that. Sort of it think of it as a check sum. And then they can go look at their government-supplied blockchain. They've got a copy of that whole blockchain. And they go back to the date that says, "This old doctor saw Anders." And he can't look up Anders’ name on there because that'd be sensitive data, but instead he can just go, "Okay, well, on that date, let's see all the hashes that were sent up by that old doctor. Yeah, right there. One of the hashes on the blockchain matches the hash that I just recomputed from the data that the old doctor sent me. So I feel more comfortable that I have the matching record of whatever was recorded on that day three years ago.”

Anders Larson: So you can prove that, and it seems like a nice thing to be able to do to validate that. But one of the things we talk about with hashes is that if that-- if you change the input just a little bit, if that doctor's EMR and they said, "Well, we poked Anders three times," and you actually only poked-- you know, when you submitted the data you only said that you poked it twice--

Shea Parkes: The hashes won't match.

Anders Larson: It won't even be close.

Shea Parkes: It won't even be close. And actually, this can be an issue with electronic medical records, as they're done in the U.S., is a lot of times the medical records are building not just a transaction history of what happened to Anders, but more of a picture of like what's, what are the conditions? What are the complications? What medications has Anders taken? And if, you know, I did so with Anders three years ago, and then today I go and things have-- since I was with Anders three years ago, and I pulled a snapshot of Anders' record and hashed it, and sent a hash to a blockchain, and I work with Anders more. He comes back. I do more things. I send more hashes. And then he disengages for a while, and then he shows up at some other doctor's office, and they send and say, "Hey, you know, what did you do with Anders three years ago?" It might actually be tough depending on the electronic medical record to recreate exactly that text record of what happened three years ago. So it might be-- it's nice to be able to do that, though. And so in Estonia, there's probably reason that the different medical record vend-- or the people selling electronic medical records software probably have a nice way to regenerate exactly what you would have said you did on that date three years ago.

Anders Larson: Right, right. So before we get into, you know, why, the data, all the data's not out there. I did want to just take this, and you know, one case we bandied about a little bit in the United States in some of the field we work in is the concept of encounter data, particularly for Medicaid health plans, submitting data to the state that's then used for all sorts of analyses and setting capitation rates. And you know, in many cases, there's encounter data submission problems where the MCO says, "I submitted this data. Why is not showing up?"

Shea Parkes: The MCO, the managed care organization?

Anders Larson: The managed care organization says, you know, "We submitted these claims to you, and it's not in this-- you're telling us you don't have a record of it. How could that be?" It does seem like potentially this is a way that you could validate that "yes" or "no" you did or did not submit this record because you could check it against a hash.

Shea Parkes: Yeah, you could say like you have a-- when you submitted it, you get sort of a receipt back that is the hash. And then everyone's keeping, it's getting added, maybe to a blockchain. Let me talk about it a second here. And everyone's keeping a list of all of these hashes, and then you said you could come back later and go, "Well, hey I did this," you know? "Here's what I think I did. And here's the hash of where it was acknowledged in this sort of receipt I got earlier this year whenever it happened."

Anders Larson: Right.

Shea Parkes: Now the thing I said right there was, it doesn't, you know, we're talking about blockchains here, it-- we could just be keeping a file that's just a list of all the hashes. Like there isn't actually something specific to blockchain right here.

Anders Larson: Right, because they-- in the bitcoin sense, going back to that, the chaining was really a way to build into this immutability because you'd have to essentially recreate this entire chain. So the fact that these were linked-- and the order of operations of transactional data till you had this much money at this point.

Shea Parkes: Yeah, you had a ledger going on. Money was-- so that money was flowing back and forth.

Anders Larson: The order was important, and the chaining was important. In this case like you're saying, you could essentially just use the hash function as the receipt.

Shea Parkes: Yeah, well, I mean, you probably want to know what was the exact date, and maybe what was the provider when someone's looking it up later, you know? Which doctor's office?

Anders Larson: Right.

Shea Parkes: But there's no reason it actually has to be a blockchain. Now text file is a little extreme, but it could be a traditional database. There could just be a traditional database that all the doctor's offices have access to, and they just say, "You know, here's the list." Now that way, you'd have to trust that the government wasn't compromised. So maybe all the doctor's offices keep copies of the databases locally, but then how do you make sure all those databases are in sync, and yeah, okay, you know, blockchain, part of that idea of having that distributed ledger can be nice. So there's some niceties to using that blockchain. Although, in a lot of cases, I'm not sure that all the doctor's offices will be sophisticated enough to not notice if someone were to edit the data, you know, that somehow, or change the software so it actually edited the chain that they've been storing locally. But maybe in theory somehow they make a copy of the chain every night, and keep it off somewhere secure or something.

Anders Larson: Right.

Anders Larson: Right, so let's circle back to Estonia. They are conspicuously not storing all the data, all the medical record that says exactly, "Anders did X, Y. and Z," on the blockchain. Why are they not doing that, Shea?

Shea Parkes: Well, they're not doing that because you're keeping copies of all these receipts and records everywhere, right? And if you stored all the data on there, even if it was encrypted, there are still keys that decrypt encryption. In fact, honestly, if you encrypt it, you would probably do public/private key cryptography possibly. Or maybe not. You wouldn't have to do that. You could just do-- you know, scrap that part.

Anders Larson: Again, we're talking about encrypting-- we're encrypting the key. You still can't reverse engineer these hashes, but if you store all the data out there, now everything's out there.

Shea Parkes: Everything's out there, and if the key-- not only is everything out there, but if you distribute that data to all the doctor's offices, they would all have all the data for all the people in Estonia. Now they don't have access to it right now, but later, if you accidentally-- someone, either nefariously or accidentally, compromised and shared that private key, well, then you had so many copies of this data going around that you don't have any way to take that data back, so someone's going to be able to take that key and decrypt the data. So encryption is just one layer of protection. It should not be the only layer of protection you use. So talking about storing data encrypted, just because I encrypt my data doesn't mean that I make it publicly available. You want layers of security on really sensitive data like protected health information that you want to encrypt it and limit access. And so, in a scenario like this, you really don't want to have copies of everyone's medical data strewn all across the country.

Anders Larson: So we've talked about Estonia and some of the compromises they've made and what they are doing, and what they're getting out of it. There are a handful of other use cases going on out there. Probably more-- certainly more than we're going to be able to mention here. You know, one of the concepts is the idea of smart contracts that are based on agreed upon code that are leveraging like an Ethereum or some other blockchain currency. There are the ability to verify asset ownership is something that people have looked at. One thing we did want to talk about today in a slight bit more detail is version control. And how blockchain is used there. Actually already is being used.

Shea Parkes: Yeah. So this is one where we get to maybe bend the term a little bit. So when we talk about blockchain, this is where we led off in the first episode. We're meaning many different things. You know, there's a specific blockchain for a cryptocurrency. There's the abstract idea of a blockchain, distributed ledgers, or there's just the data structure that it's – a data structure composed of blocks. For each block you store, you make sure to also store the hash of the content of that block. And then each time, each block also contains a hash of its prior block, so you get a chain of blocks, thus a blockchain. So even without worrying about a distributed blockchain, there can be reason that it would be nice to just store information in a blockchain if there was a reason for that data model to make sense.

So a great example of when just that data model of just storing on a single computer, a chain of blocks can be when you're trying to keep version history of a file, a directory of anything, you have a chain of blocks, where each block in that chain is a different version of either a file or a directory, an asset or anything like that. And honestly, that data structure is used in a lot of version control software. And so some of the most common ones being Git - it was one of those that really championed an idea that you had that blockchain behind it. Now, I don't think they put capital "B" and capital "C" on blockchain in an advertising, but Git's been around for many years now. You know, as long as bitcoin or longer. So if you've been using that for version control or many other softwares, you've been definitely working with blockchains. They have their own distributed nature, and trust plays into that, and probably more than we're going to talk about today. But one thing I will say, this does come up a lot, in the insurance industry under "model governance," it comes up in a lot of needs to be able to track. Work in the insurance industry gets more and more complex, and models get more and more complicated. You really want to bring in best practices from software development and things like version control, and use software like Git and other ones, and have this idea of a chain of blocks of what the different versions were over time. So with that, that's another sort of slightly abstract, but pretty con-- well, you abstracted the idea of a blockchain, but it's still a very concrete use case of model governance and version control.

Anders Larson: Right, so I think in this episode, and we've been talking, preparing for this episode, it's sort of been an interesting thought exercise of…taking kind of everything that's in that bitcoin model of blockchain, like maybe you mentioned the capital "B"/capital "C", and sort of bending that concept and taking pieces of it and thinking about what blockchain is at maybe a more foundational level and how those concepts can be used.

Shea Parkes: Yeah, or you know, just sort of muddying the waters on the term a little bit.

Anders Larson: Right.

Anders Larson: So with that, we'll leave it there for today. We're hoping to come back potentially in the future with a discussion of some use cases, very specific use cases from some other folks at Milliman. But for today, we'll leave it there and hope you've enjoyed this one, and get you interested in what there is out there for blockchain in insurance applications. So, Shea, thanks for joining me again.

Shea Parkes: Thank you very much, Anders. And I can promise that no shoulders were injured in the recording of this podcast.

Anders Larson: No, and in fact, due to – for being HIPAA compliant, I can neither confirm nor deny that I have any shoulder injury. So thank you very much. You've been listening to Critical Point, presented by Milliman. To listen to other episodes of our podcast, you can visit us at milliman.com or find us on iTunes, Google Play, Spotify and Stitcher. See you next time.