[00:09.070 --> 00:13.130] So I'm fortunate enough to have met a lot of physicians who are interested in bridging [00:13.130 --> 00:18.210] that gap between their world and ours. And I've had the opportunity to work with them [00:18.210 --> 00:23.530] in the past. We did some research in the past, DEF CON 22, I think, on 9-1-1 security, presented [00:23.530 --> 00:27.590] on that, and continue to work through things like I Am the Cavalry to talk about health [00:27.590 --> 00:32.410] care and information security. And that's been awesome. Ryan and I have a shared background [00:32.410 --> 00:36.450] in that we both went to the Air Force Academy, we both did space and missiles and some other [00:36.450 --> 00:41.010] stuff, and he came to me with the idea of this application and this concept, and we [00:41.010 --> 00:45.590] said, heck, let's run with it. So we did this part. [00:49.100 --> 00:54.710] Okay, I already covered most of this, I was just trying to feel like I was going to make a [00:54.710 --> 01:05.590] microphone. This is annoying. If I don't face the camera, is that okay? Okay, so, just to [01:05.590 --> 01:08.130] reiterate, it seems like we're all familiar with this technology, so let's press, let's get [01:08.130 --> 01:17.010] right into it. Slide. Oh, no, I'll take this. So over the last, I mean, these are pretty [01:17.010 --> 01:21.990] current, 6 months, 7 months, we've just seen hack after hack. So this is something we were [01:21.990 --> 01:27.990] trying to address with this sort of relatively simple system for protecting our health care [01:27.990 --> 01:33.890] records, our health care transactions, our health care communication. This is going to [01:33.890 --> 01:38.090] happen again, this is going to continue happening, and one of these days it's going to hit a [01:38.090 --> 01:41.990] system that everyone uses, like Epic or Cerner. Anyone familiar with Epic or Cerner in here? [01:41.990 --> 01:46.990] Okay, good, very good. Okay. And when that happens, I mean, it's going to be a shit [01:46.990 --> 01:51.250] storm. I mean, there's really nothing you can do because there's no redundant comm built [01:51.250 --> 01:58.250] in, there's no, there's no plan B. This system, TriGraph, what we're building now is not [01:58.250 --> 02:02.150] going to be that plan B yet, but we hope that in the future this or something like it will [02:02.150 --> 02:09.030] be. So this is just the scare tactics to keep you engaged. Next slide. Alright, so, yes, [02:09.030 --> 02:12.650] this is the obligatory legal language that we have to provide that was developed by [02:12.650 --> 02:18.450] trained ninja JD monkeys. Here, this is just to reflect that this is not necessarily the [02:18.450 --> 02:24.450] opinions or the language, verbage, opinions, commentary associated with our employers. [02:25.290 --> 02:30.750] His, whether it be the medicine field, yeah, he's still technically in the Air Force and [02:30.750 --> 02:35.210] he's in the medicine field, he's not going to provide any medical advice here, anyhow. Oh, [02:35.210 --> 02:39.730] and patent pending, the work we've done here. Alright, so this is objective. [02:45.210 --> 02:51.170] We did ask for a second microphone. Do we have enough cable to do this or what? Okay. Alright, [02:51.170 --> 02:54.410] so long term we want to improve access to physician care. I mean, that's, that's the big [02:54.410 --> 02:58.190] takeaway here. And finally, we think that going forward medicine is going to have to become [02:58.190 --> 03:04.290] more collaborative. Raise your hand if you've been on WebMD. I know, I know you all have. [03:04.290 --> 03:08.510] You've all had some weird sore, yeah. I know you all have. Something a little itchy? [03:08.510 --> 03:17.670] You're, you're gross. Um, yeah. So, we think that it'll be helpful to be able to speak over a [03:18.490 --> 03:21.510] secure anonymous platform and say, hey man, I got this thing going on. Kind of like what you [03:21.510 --> 03:25.150] have on WebMD right now, except with someone that you know is a physician because they've [03:25.750 --> 03:30.870] been credentialed through the blockchain, through a token, uh, to, to know that. Uh, next [03:30.870 --> 03:34.990] slide. Longer term, and this is what I alluded to earlier, um, right now we have a functional [03:34.990 --> 03:39.550] POC. We're going to show you that today. Um, it's sped up though, so don't think we're [03:39.550 --> 03:44.410] cheating. It takes longer than a minute to do this. It takes like 6 minutes to do this, which [03:44.410 --> 03:49.630] is still pretty good, we thought. Um, so these are the, the key tenets I want you to keep in [03:49.630 --> 03:55.250] mind as we go through this. Uh, the one I didn't mention was auditability. So, for anything [03:55.250 --> 04:01.250] medical records, you have to be able to know who looked at what, what they saw, you know, if [04:01.250 --> 04:06.630] they had a reason for doing this. Um, a blockchain will keep track of the externals, so [04:06.630 --> 04:12.890] you'll know that physician X talked to patient Y, maybe some sort of content, I guess with the [04:12.890 --> 04:18.470] contract on Ethereum you'll know that it was something about, uh, I think I maybe broke this [04:18.470 --> 04:23.750] bone or something. Um, but you won't have the internals, so there's still privacy, uh, we, we [04:23.750 --> 04:27.290] hope, we think at play, although we're, we are looking to you guys to help pick this apart. [04:27.290 --> 04:34.630] Uh, next slide. So why Ethereum? Um, you know, it's kind of a, a, you know, a poor man's [04:34.630 --> 04:38.070] crypto. We can do a lot of stuff with this, with the blockchain. It'll cost a little bit of [04:38.070 --> 04:43.450] money, but even more importantly, what we're up against is, is frankly way too expensive to [04:43.450 --> 04:47.970] begin with. I mean, a PAC system is millions a year and it's proprietary. Oh, and there's a [04:47.970 --> 04:51.870] talk on Sunday, I don't know who's giving it, but, uh, I think they're going to discuss the [04:51.870 --> 04:56.370] security, any chance he or she's in here? No? Okay, well they're going to hopefully talk [04:56.370 --> 05:02.570] about all the, the vulnerabilities in PAC systems that already exist. Um, additionally, [05:03.230 --> 05:07.230] healthcare, the, the costs have become just non-transparent. I mean, we, we think we're [05:07.230 --> 05:11.470] over a hundred dollars to read a, an x-ray, an MRI is probably more, probably a couple [05:11.470 --> 05:17.090] hundred dollars. Um, but frankly that's, that's already too expensive and, uh, we think we [05:17.090 --> 05:20.970] can do better. We know we can do better. Uh, the, the payment system is already built in, [05:20.970 --> 05:24.090] as long as your physician is willing to accept Ethereum. Who here, who in here takes [05:24.090 --> 05:29.590] Ethereum? I think I took a nose dive the last few weeks. Who lost thousands? Yeah, yeah, [05:29.590 --> 05:34.550] sorry buddy. Um, and then, uh, identity management, this is where we really think this [05:34.550 --> 05:40.970] could catch on, um, because how do you know who you're talking to? How do you know this is a [05:40.970 --> 05:44.770] physician? Um, especially if you can de-identify it enough to know that, well, I don't know [05:44.770 --> 05:48.430] the physician's name, but I know that he's credentialed to this level, even if he or she is [05:48.430 --> 05:53.070] living in India or even if he or she is living, uh, you know, in Chile or something, uh, which [05:53.070 --> 05:57.650] can also help for 24-7 access to these kinds of, uh, medical services. And finally, [05:57.650 --> 06:01.250] reputation management. We're not here yet, but we envision something along the lines of an [06:01.250 --> 06:06.010] Uber-type rating system, which is difficult because you might not like what you hear from [06:06.010 --> 06:13.530] the physician. Yes, you do have herpes, I'm sorry. Um, but, uh, you know, we're, we're [06:13.530 --> 06:16.690] hoping that someday we can put together something that allows us to know that this [06:16.690 --> 06:21.710] physician who is credentialed and operating on this, this particular system is not full of [06:21.710 --> 06:24.790] shit. Um, that's kind of where we, what we want to get to. [06:26.810 --> 06:30.470] So, when you're getting feedback from a physician on an image that you're providing to [06:30.470 --> 06:34.290] them, you want to make sure you're getting timely feedback, you're getting cost effective [06:34.290 --> 06:38.610] feedback, and that it's detailed enough that you can take it and provide it to maybe your [06:38.610 --> 06:43.310] primary care provider, or you get enough input on it to say, yes, this is a broken, or, [06:43.310 --> 06:45.770] yeah, that probably is what you think it is, that's sore. [06:46.610 --> 06:53.190] Slide. Slide. All right. So, this is me. So, this is the, the architecture, what we [06:53.190 --> 06:57.570] designed, um, to get this done. And on the left-hand side, you've got the patient, and on [06:57.570 --> 07:01.030] the right-hand side, you've got a physician. And originally, when we were talking about [07:01.030 --> 07:05.810] this and designing it in our heads, trigraph was the concept of the patient, the [07:05.810 --> 07:09.810] blockchain, and the doctor. And then we got to the point where we said, hey, you know [07:09.810 --> 07:13.390] what, we probably don't want to store imagery on the blockchain. That would be annoying for [07:13.390 --> 07:20.750] everybody. So, we didn't. We ended up using an external data store. And the external data [07:20.750 --> 07:24.350] store is depicted on the top. We've implemented that in the proof of concept using [07:24.350 --> 07:30.790] Django. And that's just basically an API that's sending information back and forth. In [07:30.790 --> 07:34.010] the design phase, when we were looking at this, it was very important to us that we [07:34.010 --> 07:38.490] implement it such that if the data store were compromised, none of the patient [07:38.490 --> 07:43.910] information, specifically imagery, would be recoverable. So, what is passed up there is [07:43.910 --> 07:49.590] public keys and encrypted image data, and that's it. As far as the patient interaction [07:49.590 --> 07:53.130] with the blockchain, that's something where they're sending the payment. They're paying [07:53.130 --> 07:57.190] the physician for that imagery. They're paying the physician for that opinion. They're [07:57.190 --> 08:01.110] starting the contract, and they're pushing state changes. The physician is also pushing [08:01.110 --> 08:04.870] state changes, which we'll get to here in a moment. And then the payment at the end goes to [08:04.870 --> 08:10.890] that happy physician in the lower right to say, yeah, that doesn't look good. All right, so [08:10.890 --> 08:15.850] when we designed the proof of concept, this is what we actually implemented in our network [08:15.850 --> 08:21.910] for testing. You can see basically it's a summary of it all, and this is truly a mesh [08:21.910 --> 08:27.350] network with the geth or the Go-based Ethereum clients talking to each other. But here what [08:27.350 --> 08:31.210] you've got is you've got at the top the dedicated blockchain nodes that are operating the [08:31.210 --> 08:34.730] blockchain. They're the ones that are doing the mining, and the mining is required so that [08:34.730 --> 08:39.650] we can keep the transactions moving along. On the lower hand side, this was our implementation [08:39.650 --> 08:43.690] in the proof of concept to say we have an arbitrary patient client, we have an arbitrary [08:43.690 --> 08:47.510] doctor client, and we have the data store. And the data store was the implementation of [08:47.510 --> 08:53.110] that Django app that we were talking about. All of those three are interfacing through [08:53.790 --> 09:02.990] Web 3, a Python library, into the Go Ethereum client via RPC to the Go Ethereum client and [09:02.990 --> 09:07.570] talks on the blockchain. So this is how we implemented our proof of concept. And we'll go [09:07.570 --> 09:13.050] over that and actually have some video on that later. Any questions? Okay. I'm going to [09:13.050 --> 09:16.590] speed through this. All right. So one of the things that was important to us was [09:16.590 --> 09:21.430] authentication. How do we know who's talking, right? How do we know who's conversing? So for [09:21.430 --> 09:27.030] authentication on the blockchain, we're relying on the Ethereum authentication, right? You're [09:27.030 --> 09:31.030] unlocking your wallet. You're using those secrets that are within that wallet, that private [09:31.030 --> 09:37.030] key, to send data, to send money, to send Ethereum. If you can unlock that, then you have [09:37.030 --> 09:41.390] authenticated yourself to the blockchain. And for our purposes, we said that's going to be [09:41.390 --> 09:46.210] good enough, right? Because you're already doing that to send money back and forth. But for [09:46.210 --> 09:50.850] the data store, we had to come up with something, right? How do we know who is talking to the [09:50.850 --> 09:55.930] data store? So what we came up with was this is our prescription pad, right? You have a [09:55.930 --> 09:59.790] prescription pad, you hand it to the physician and they sign it. That's what we're doing, [09:59.790 --> 10:05.450] right? So the data store, when it is working with any one of the clients to it, whether it be a [10:05.450 --> 10:09.870] patient or a physician, they're sending them challenges. It's a challenge response [10:09.870 --> 10:13.910] authentication mechanism that's essentially saying, hey, here's something that's unique, a [10:13.910 --> 10:19.610] unique token from the data store. We want you to sign it with your Ethereum private key. And [10:19.610 --> 10:23.970] when it gets back, the data store looks at it and tries to verify that signature and if it can, [10:23.970 --> 10:28.930] and that contract ‑‑ I'm sorry, that address verifies up against the contract that it's [10:28.930 --> 10:33.630] looking for to say, yes, this is the patient, yes, this is the physician, you're good to go. [10:33.630 --> 10:37.650] And it progresses forward. So that was used for authentication against the data store. The [10:37.650 --> 10:41.350] other thing that was important to us was authorization. And authorization was handled at [10:41.350 --> 10:47.450] two levels. Authorization in the contract on the blockchain was baked into the contract using [10:47.450 --> 10:51.530] solidity. So you can see here we've got some modifiers that say only the patient can do [10:51.530 --> 10:55.430] certain things, only the doctor can do certain things. And then we've got the in‑state [10:55.430 --> 11:00.630] aspects. And you've got some examples on the right‑hand side. In‑state just depicts the [11:00.630 --> 11:04.830] fact that we've got this kind of positioned out in different states where the contract is [11:04.830 --> 11:09.210] initiated by the patient and then it waits for it to be ready for the doctor and then the [11:09.210 --> 11:12.490] doctor picks it up and reviews it and then it gives it back to the patient and the patient [11:12.490 --> 11:17.310] gets it and says, yes, you reviewed my image, here's your money. So that's basically how [11:17.310 --> 11:22.110] we're doing that authorization. As far as authorization within the data store, that was [11:22.110 --> 11:27.850] based on your authentication. So it's, again, based on patient or physician. If you have [11:27.850 --> 11:32.490] identified yourself using the authentication mechanism we referenced in the last slide as [11:32.490 --> 11:35.170] the patient and you're trying to do something a patient should be able to do with that [11:35.170 --> 11:42.550] contract, you're authorized to do it. All right. So how did we keep those images secure on [11:42.550 --> 11:47.130] the data store? This is basically a summary of what we did. This is a specific [11:47.130 --> 11:53.550] implementation of elliptic curve integrated encryption scheme or ECIES. What we're doing is [11:53.550 --> 11:57.250] we're taking that Ethereum private key data on the left-hand side for the patient and the [11:57.250 --> 12:02.830] doctor and we're creating elliptic curve keys, basically saying let's create pubs from the [12:02.830 --> 12:08.190] private key data that you have and we're going to share the public keys via the data store. [12:08.190 --> 12:12.290] Again, that's authenticated back to say, are you the patient? Okay, then you get the [12:12.290 --> 12:16.210] doctor's public key. Are you the doctor? Okay, then you get the patient's public key. [12:16.210 --> 12:21.510] Specifically for that contract. The public keys are exchanged via the data store and then [12:21.510 --> 12:25.790] those are used for ECDH or elliptic curve Diffie-Hellman key exchange, right? So we're [12:25.790 --> 12:31.190] going to take that and we're going to generate a shared secret that now the patient and the [12:31.190 --> 12:36.910] doctor have. That shared secret is used as output from the ECDH or elliptic curve Diffie-Hellman [12:36.910 --> 12:43.190] blocks to throw into an AES key derivation function and the salt that we're using to make it [12:43.190 --> 12:49.750] unique for each exchange is the contract address from Ethereum. That then will result in [12:49.750 --> 12:55.470] equal AES keys on each side. So the doctor has an AES key, the patient has an AES key, they're [12:55.470 --> 13:00.970] the same but they never exchange it in the first place. So these are the stages that the [13:00.970 --> 13:05.790] contract will go through. The patient will initiate it, the patient will stage everything, [13:05.790 --> 13:10.450] put the data out there, say it's ready for the doctor, the doctor can then accept the [13:10.450 --> 13:15.530] contract and get everything ready to be able to, you know, exchange those public keys. Once [13:15.530 --> 13:21.630] the public keys are exchanged, then the patient can upload the file and in the encrypted [13:21.630 --> 13:28.250] format and then it can be downloaded by the doctor, reviewed, put back up there and then the [13:28.250 --> 13:33.850] patient can say, yes, this is completed, I got back the advice from the doctor. There's also a [13:33.850 --> 13:39.290] stage for abortion. If we get to a point where the patient has put a contract out there and it [13:39.290 --> 13:43.830] has not been accepted, for example, if I put something out there and I didn't mean to or I put it [13:43.830 --> 13:47.910] out there and the value is too high or I want to decrease it, you can just nix the contract [13:47.910 --> 13:53.170] altogether. But it has to be a non-accepted state and it has to be done by the patient. We've [13:53.170 --> 13:57.470] got some details in this for everything I just said that I'm just going to skip past because I [13:57.470 --> 14:00.070] said it already. All right. Challenges? [14:03.370 --> 14:10.970] Okay, so it's changing quickly. That could wreck all the code that Peter has already written. [14:10.970 --> 14:19.030] Sorry. There are privacy concerns. Just like any system, the end users can still take a picture of [14:19.030 --> 14:22.850] something and put it on the Internet. We don't know how to fix that, so we can't really solve [14:22.850 --> 14:30.750] that problem. Additionally, de-identifying some of this data may prove impossible. Moral and [14:30.750 --> 14:36.130] ethical as well. This is something that Peter and I discussed at length for about 10 minutes [14:36.130 --> 14:44.690] over a few beers. This same construct could be used to share some really bad stuff and it would [14:44.690 --> 14:51.830] be completely anonymous and it would be completely secure. So you could do murders for [14:51.830 --> 14:57.650] hire. I'll let you speculate on everything else you could do over that. Finally, how do I [14:57.650 --> 15:01.070] know you're a real doctor? If you lose your token once it's been issued or if it's stolen from [15:01.070 --> 15:08.990] you, well, we don't know that you're talking to a real doctor anymore. And then finally, two [15:08.990 --> 15:13.370] more things. So you do, we're not sure what's going to happen with this. The gas when we [15:13.370 --> 15:16.570] priced it a few days ago was just a few cents. The physician would pay a few cents to get [15:16.570 --> 15:21.490] into the network, which is no big deal. But we don't know what the future is going to hold [15:21.490 --> 15:25.690] with that. So if Vitalik Buterin is around, does anyone know if he's around? I'd like to talk to [15:25.690 --> 15:31.950] him. I'm totally serious. I'd love to sit down and, you know, is he 21 yet? And finally, [15:31.950 --> 15:35.570] speed kills. If the network isn't fast enough, your average radiologist is going to move [15:35.570 --> 15:40.930] through a scan in about two minutes. If they can't do that in that sort of time with this [15:40.930 --> 15:47.670] network, it's pointless. They'll just go back to a pack system. Slide. Next step. So what we [15:47.670 --> 15:56.130] want to do, um, we, we need to automate more of this. It needs to be, um, I'm not sure what [15:56.130 --> 16:02.610] you meant by checks and balances. So right now, so right now we don't have some of the checks [16:02.610 --> 16:07.310] that I'd like to do. I'd like to do some of those things to say, okay, um, you know, where is [16:07.310 --> 16:12.030] the state of the contract with respect to what you're doing at the data store? Right? So if [16:12.030 --> 16:16.810] you're trying to download an image and it isn't actually at that state on the, the data or on [16:16.810 --> 16:23.890] the blockchain, it'll all error out, but I'd like to tighten that up. Yeah. Thanks Pedro. Um, [16:23.890 --> 16:27.290] so we need to also credential physicians. How much time do we have? A minute or two? Okay, [16:27.290 --> 16:31.370] cool. Um, so this is the hard part. If anyone knows any companies that can do this for us, [16:31.370 --> 16:35.230] we'd love to know. Um, because once they're credentialed, I mean, that's it. We don't have [16:35.230 --> 16:38.570] any way to sort of police them. We need to know that they are who they say they are, that [16:38.570 --> 16:43.070] they have gone to this residency or have had this medical training. Uh, user friendly [16:43.070 --> 16:46.930] interface right now. Um, there's maybe three people in this room who would know how to do [16:46.930 --> 16:53.090] this, uh, in this system. Um, so we're going to need to make this interface with a browser [16:53.090 --> 16:58.170] of some sort or an app. Uh, if anyone can do that, let us know afterwards. Uh, [16:58.170 --> 17:02.070] monetization. Uh, we do, we would like to monetize it. I mean, I don't, I don't think we're [17:02.070 --> 17:06.470] looking to make crazy profits on this, but there's a few different ways we could do it, but [17:06.470 --> 17:10.410] we want to do it in a way that we're not a third party. It would have to be the sort of thing [17:10.410 --> 17:14.910] where the contract is already fulfilled and everyone's happy and then somehow in some sort [17:14.910 --> 17:19.850] of, you know, subcontract or something, we're paid afterwards. We're not exactly sure how [17:19.850 --> 17:23.390] we're going to do that yet. Um, the rating system, already discussed. Go live on Ethereum. [17:23.390 --> 17:27.670] We haven't done this yet. Uh, so we still technically don't know if this will work and end [17:27.670 --> 17:33.270] because it hasn't been done, uh, on the live network. Okay, uh, I hope we left time for [17:33.270 --> 17:52.330] questions. Let's get the demo going. Uh, and wow, this is really terrible, terrible [17:52.330 --> 17:59.950] graphics. I'm so, so sorry about this. Let's see if we can zoom in. How do you max zoom in? [18:01.170 --> 18:21.070] Max zoom in. Yeah. And we can make this available afterwards. This is just a video. It's [18:21.070 --> 18:25.730] unfortunately grainy. Um, what this is and was, we sped this up. This is a video of the [18:25.730 --> 18:30.470] interaction on the top of an end to end script. The problem with, uh, actually doing this, [18:30.470 --> 18:34.450] you know, in person is it's something where I would do something as a patient, doctor would do [18:34.450 --> 18:37.290] something. I would do something as a patient, doctor would do something. And that's [18:37.290 --> 18:41.110] actually going to take hours and hours. Plus the blockchain has to mine everything to [18:41.110 --> 18:45.850] verify all the transactions. So, so my question is, have you felt of running, uh, instead of [18:45.850 --> 18:51.110] using public blockchain, you can use a private blockchain, let's say based off on a proof of [18:51.110 --> 18:58.030] authority consensus or similar to oracles.org project that they're trying to do. Um, have you [18:58.030 --> 19:02.410] thought of this approach? Because it's a green mining, nobody has to, it's like a simplified [19:02.410 --> 19:10.210] proof of stake. Yeah. So what he said was right now we're using a private blockchain and it's [19:10.210 --> 19:14.730] working. Um, we do want to push it out to a public blockchain just to make it so that it's [19:14.730 --> 19:21.090] readily available. It's monetized right there. It's money, right? People pay, right. People pay [19:21.090 --> 19:26.410] in the money. Yeah. We can do very bad things with this blockchain. So we want to make sure [19:26.410 --> 19:30.230] that it's verified by other people. We want to make sure that it's money that people can get, [19:30.230 --> 19:33.530] that they, you know, radiologists can do this thing. They get their Ethereum and they get it [19:33.530 --> 19:40.970] out of Coinbase or whatever they need to do. All right. Last question. Okay. Um, so I see you [19:40.970 --> 19:46.710] guys aren't really storing, um, patient information, but you are storing encrypted image [19:46.710 --> 19:54.050] data. Yes. Maybe certain what patient information, um, would HIPAA apply here? Are you [19:54.050 --> 19:58.530] taking that into consideration that you'd be legally required to do certain things [19:58.530 --> 20:06.990] according to HIPAA? Yeah, why don't you take this one? No. Okay. Enjoy. No, because, [20:06.990 --> 20:10.990] because this is, this, in this case, in all the scenarios we, we are putting up here, it's [20:10.990 --> 20:16.050] the patient uploading this. With your medical records, you can do whatever you want. Um, now [20:16.750 --> 20:21.050] going forward, we would need to get some sort of HIPAA certification for this. I don't know [20:21.050 --> 20:27.570] that it would be a huge problem because once this stuff is encrypted, it, it's there in the [20:27.570 --> 20:31.670] data store and it's just there. HIPAA has very strict regulations of how you store it and how [20:31.670 --> 20:35.430] you audit the server and how you do everything. I violated it a few times. I'm familiar with [20:35.430 --> 20:41.410] it. Um, yeah, enjoy the fines. Um, yes, there are, there are heavy fines. Um, so no, we, we [20:41.410 --> 20:46.190] see this starting off as a poor man's second opinion to begin with. Um, that would be [20:46.190 --> 20:49.530] outside the bounds of HIPAA. But you're right, going forward, that, that would be a problem [20:49.530 --> 20:53.290] and a concern. And not one we're really that worried about because when you start talking [20:53.290 --> 20:57.470] about auditability, this is the public ledger, right? This is the blockchain. So now we kind [20:57.470 --> 21:01.370] of know where everything's transiting. It's your data store. So the data store also supports [21:01.370 --> 21:05.270] all kinds of logging that we can do with that. It's something that we could achieve. I'm not [21:05.270 --> 21:09.150] that concerned about it. But to get to the point where we were proof of concept and it was [21:09.150 --> 21:12.670] actually moving data back and forth in an encrypted fashion, we did not achieve HIPAA [21:12.670 --> 21:19.350] compliance today. All right, cool. Thanks guys. Oh! [21:19.410 --> 21:21.790] >>[applause from audience, no audio for the rest of the presentation.