You need the mic, okay. Turn it on then. All right, so I'm fortunate enough to have
met a lot of physicians who are interested in bridging that gap between
their world and ours and I've had the opportunity to work with them in the
past. We did some research in the past, DEFCON 22 I think on 911 security
presented on that and continue to work through things like I am the cavalry to
talk about health care and information security and that's been awesome. Ryan
and I have a shared background in that we both went to the Air Force Academy, we
both did space and missiles and some other stuff and he came to me with the
idea of this application, this concept and we said heck let's run with it. So we
did this part.
If I don't face the camera is that okay? Yes. Okay. So just to reiterate, it seems like
we're all familiar with this technology. So let's press, let's get right into it. Slide. That's
me. That's you. I'll take this. So over the last I mean these are pretty current, six months,
seven months. We've just seen hack after hack. So this is something we were trying to
address with this sort of relatively simple system for protecting you know, security and
our health care records, our health care transactions, our health care communication. This
is going to happen again. This is going to continue happening. And one of these days it's
going to hit a system that everyone uses like Epic or Cerner. Anyone familiar with Epic or
Cerner in here? Okay, good. Very good. Okay. And when that happens, I mean, it's going to be a
shit storm. I mean, there's really nothing you can do because there's no redundant com built
in. There's no Plan B. This system, TriGraph, what we're building now is not going to be that
Plan B yet, but we hope that in the future this or something like it will be. So this is just
the scare tactics to keep you engaged. Next slide. All right. So, yes. This is the
obligatory legal language that we have to provide that was developed by trained ninja J.D.
Monkeys. Here, this is just to reflect that this is not necessarily the opinions or the
language, verbiage. This is just to reflect that this is not necessarily the opinions or the
commentary associated with our employers. His, whether it be the medicine field. Yeah. He's
still technically in the Air Force and he's in the medicine field. He's not going to provide any
medical advice here anyhow. Oh, and patent pending. The work we've done here. All right. So
this is objective. We did ask for a second microphone. Do we have enough cable to do this?
Yes. All right. So long term we want to improve access efficient physician care. I mean that's
the big take away here. And finally, we think that going forward, medicine is going to have to
become more collaborative. Raise your hand if you've been on WebMD? I know you all have.
You've all had some weird sore. Yeah. I know you all have. Something a little itchy? You're
gross. So we think it will be helpful to be able to speak over a secure anonymous platform and say,
hey, you're right. We want to improve access efficient physician care. That's the big
man, I got this thing going on. Kind of like what you have on WebMD right now except with
someone that you know is a physician because they've been credentialed through the
blockchain, through a token to know that. Next slide. Longer term, and this is what I alluded
to earlier. Right now we have a functional POC. We're going to show you that today. It's
sped up though. So don't think we're cheating. It takes longer than a minute to do this. It
takes like six minutes to do this. Which is still pretty good we thought. So these are the
key tenets I want you to keep in mind as we go through this. The one I didn't mention was
auditability. So for anything medical records, you have to be able to know who looked at what,
what they saw, you know, if they had a reason for doing this. A blockchain will keep track of
the externals so you'll know that physician X talked to patient Y. Maybe some sort of
content. I guess with the contract on Ethereum you'll know that it was something about, I
think I maybe broke something. I don't know. I don't know. I don't know. I don't know. I don't
know. I don't know. Maybe I broke this bone or something. But you won't have the internals. So
there's still privacy we hope, we think at play. Although we are looking to you guys to help
pick this apart. Next slide. So why Ethereum? You know, it's kind of a, you know, poor man's
crypto. We can do a lot of stuff with this with the blockchain. It'll cost a little bit of
money. But even more importantly, what we're up against is, is frankly way too expensive to
begin with. I mean a PAX system is millions a year and it's proprietary. Oh, and there's a talk on
Sunday. I don't know who's giving it, but I think they're going to discuss the security. Any
chance he or she is in here? No? Okay. They're going to hopefully talk about all the
vulnerabilities in PAC systems that already exist. Additionally, health care, the costs have
become just non-transparent. We think we're over $100 to read an X-ray. An MRI is probably
more, probably a couple hundred dollars. But frankly, that's already too expensive and we
think we can do better. We know we can do better. The payment system is already built in as
long as your physician is willing to accept Ethereum. Who in here takes Ethereum? I think it
took a nosedive the last few weeks. Who lost thousands? Yeah, sorry buddy. And then identity
management, this is where we really think this could catch on because how do you know who
you're talking to? How do you know this is a physician? Especially if you can de-identify it
enough to know that, well, I don't know the physician's name, but I know that he's credentialed
to the system. So I don't know who he is. So I don't know who he is. So I don't know who he is.
And we're looking for those people to help us with these kinds of things, at this level. Even if
he or she is living in India or even if he or she is living in Chile or something which can also
help for 24.7 access to these kinds of medical services. And finally reputation management,
we're not here yet but we envision something along the lines of an Uber type rating system which
is difficult because you might not like what you hear from the physician. Yes, you do have
herpes. I'm sorry. But you know, we're hoping that some day we can put together something that
allows us to know that this physician who is credentialed and operating on this particular
system is not full of shit. That's kind of what we want to get to. So when you're getting
feedback from a physician on an image that you're providing to them, you want to make sure
you're getting timely feedback, you're getting cost effective feedback and that it's detailed
enough that you can take it and provide it to maybe your primary care provider or you get
enough input on it to say yes, this is broken or yeah, that probably is what you think it
is that's for. Slide. Slide. Alright, so this is me. So this is the architecture, what we
designed to get this done. On the left-hand side you've got the patient and on the right-hand
side you've got a physician. And originally when we were talking about this and designing it in
our heads, TriGraph was the concept of the patient, the block chain and the doctor. And then
we got to the point where we said, hey, you know what, we probably don't want to store imagery
on the block chain. That would be annoying for everybody. And then we got to the point where
we actually我们不做了.我们结果我们使用了一个外来数据文件座.
And the external data store is depicted on the top. We've implemented that in the proof of
concept using Django. And that's just basically an API that's sending information back
and forth. In the design phase when we were looking at this, it was very important to us that
we implement it such if that data store were compromised, none of the patient information,
specifically the imagery, would be recoverable. So what was passed up there is public keys,
encrypted image data and that's it. As far as the patient interaction with the block chain,
that's something where they're sending the payment, right? They're paying the physician for
that image read. They're paying the physician for that opinion. They're starting the contract
and they're pushing state changes. The physician is also pushing state changes which we'll get
to here in a moment and then the payment at the end goes to that happy physician in the lower
right to say, yeah, that doesn't look good. All right, so when we designed the proof of
concept, this was what we actually implemented in our network for testing. You can see
basically it's a summary of it all and this is truly a mesh network with the Geth or the
Go-based Ethereum clients talking to each other. But here what you've got is you've got at the
top the dedicated block chain nodes that are operating the block chain. They're the ones that
are doing the mining and the mining is required so that we can keep the transactions moving
along. On the lower hand side, this was our implementation in the proof of concept to say we
have an arbitrage. This is the proof of concept. This is what we actually implemented in our
proof of concept. We have an arbitrage patient client, we have an arbitrage doctor client and
we have the data store. The data store was the implementation of that Django app that we were
talking about. All of those three are interfacing through Web 3, a Python library into the Go
Ethereum client via RPC to the Go Ethereum client and then talks on the block chain. So this is
how we implemented our proof of concept and we'll go over that and actually have some video on
that later. Any questions?
Okay. I'm going to speed through this. So one of the things that was important to us was
authentication. How do we know who's talking, right? How do we know who's conversing? So for
authentication on the block chain, we're relying on the Ethereum authentication, right? You're
unlocking your wallet. You're using those secrets that are within that wallet, that private key, to
send data, to send money, to send Ethereum. If you can unlock that, then you have authenticated
yourself to the block chain. And for our purposes, we said that's what we're going to do. We're going to
send money back and forth. That's going to be good enough, right? Because you're already doing
that to send money back and forth. But for the data store, we had to come up with something, right?
How do we know who is talking to the data store? So what we came up with was this is our
prescription pad, right? You have a prescription pad. You hand it to the physician and they sign
it. That's what we're doing, right? So the data store, when it is working with any one of the
clients to it, whether it be a patient or a physician, they're sending them challenges. It's a
challenge response authentication mechanism. It's a
message that's essentially saying, hey, here's something that's unique. It's a unique token from
the data store. We want you to sign it with your Ethereum private key. And when it gets back, the
data store looks at it and tries to verify that signature. And if it can, and that contract, or
I'm sorry, that address verifies up against the contract that it's looking for to say, yes, this
is the patient, yes, this is the physician, you're good to go. And it progresses forward. So that
was used for authentication against the data store. The other thing that was important to us was
authorization. And authorization is a very important part of authentication. It's a very important
part. Authorization was handled at two levels. Authorization in the contract on the
blockchain was baked into the contract using solidity. So you can see here we've got some
modifiers that say only the patient can do certain things, only the doctor can do certain
things. And then we've got the in-state aspects. And you've got some examples on the right-hand
side. In-state just depicts the fact that we've got this kind of positioned out in different
states where the contract is initiated by the patient and then it waits for it to be ready for
the doctor. And then the doctor picks it up and reviews it. And then the doctor picks it up and
gives it back to the patient. And the patient gets it and says, yes, you reviewed my image,
here's your money. So that's basically how we're doing that authorization. As far as
authorization within the data store, that was based on your authentication. So it's, again,
based on patient or physician. If you have identified yourself using the authentication
mechanism we referenced in the last slide as the patient and you're trying to do something a
patient should be able to do with that contract, you're authorized to do it. All right. So how did
we keep those images secure on the data store? This is basically a summary of what we did. This
is a specific implementation of elliptic curve integrated encryption scheme, or ECIES. What we're
doing is we're taking that ethereum private key data on the left-hand side for the patient and
the doctor and we're creating elliptic curve keys, basically saying let's create pubs from the
private key data that you have. And we're going to share the public keys via the data store.
Again, that's authenticated back to, say, the private key data that you have. And we're going to
say, are you the patient? Okay, then you get the doctor's public key. Are you the doctor? Okay,
then you get the patient's public key, specifically for that contract. The public keys are
exchanged via the data store and then those are used for ECDH, or elliptic curve Diffie-Hellman
key exchange, right? So we're going to take that and we're going to generate a shared secret that
now the patient and the doctor have. That shared secret is used as output from the ECDH, or
elliptic curve Diffie-Hellman blocks, to throw into an AES key. And then we're going to use that as a
key derivation function. And the salt that we're using to make it unique for each exchange is the
contract address from Ethereum. That then will result in equal AES keys on each side. So the
doctor has an AES key, the patient has an AES key. They're the same, but they never exchange it
in the first place. So these are the stages that the contract will go through. The patient will
initiate it. The patient will stage everything, put the data out there, say it's ready for the
doctor. The doctor can then accept the key. And then the contract will go through. The patient will
accept the contract and get everything ready to be able to, you know, exchange those public keys.
Once the public keys are exchanged, then the patient can upload the file. And in the encrypted
format. And then it can be downloaded by the doctor, reviewed, put back up there. And then the
patient can say, yes, this is completed. I got back the advice from the doctor. There's also a
stage for abortion. If we get to a point where the patient has put a contract out there and it has
not been accepted, for example, if I put something out there and I didn't mean to or I put it out
there and the value is too high or I want to decrease it, you can just nix the contract
altogether. But it has to be in a non-accepted state and it has to be done by the patient. And
we've got some details in this for everything I just said that I'm just going to skip past because
I said it already. All right. Challenges. Okay. So it's changing quickly. That could wreck all
the code that Peter's already written. Sorry. There are privacy concerns. Just like any system,
the end users can still take a picture of something and put it on the Internet. We don't know
how to fix that. So we can't really solve that problem. Additionally, de-identifying some of
this data may prove impossible. Moral and ethical as well. This is something that Peter and I
discussed at length for about ten minutes over a few beers. I'm sorry. I'm sorry. I'm sorry. I'm
sorry. This same construct could be used to share some really bad stuff. And it would be
completely anonymous and it would be completely secure. So you could do murders for hire. I'll
let you speculate on everything else you could do over that. Finally, how do I know you're a
real doctor? If you lose your token once it's been issued or if it's stolen from you, well,
it's, we don't know that you're talking to a real doctor anymore. And then finally, oh
two more things. So you do, we're not sure what's going to happen with this. The gas when we
priced it a few days ago was just a few cents. The physician would pay a few cents to get into the
network. Which is no big deal. But we don't know what the future is going to hold with that. So
if Vitalik Buterin is around, does anyone know if he's around? I'd like to talk to him. I'm
totally serious. I'd love to have him sit down, you know. Is he 21 yet? And finally, speed kills.
If the network isn't fast enough, your average radiologist is going to move through a scan in
about two minutes. If they can't do that in that sort of time with this network, it's
pointless. They'll just go back to a PAC system. Slide. Next step. So what we want to do, we need
to automate more of this. It needs to be, I'm not sure what you meant by checks and balances.
Right now, so right now, we don't have some of the checks that I'd like to do. I'd like to do some
of those things to say, okay, you know, where is the state of the contract with respect to what
you're doing at the data store, right? So if you're trying to download an image and it isn't
actually at that state on the data or on the blockchain, it'll all error out. But I'd like to
tighten that up. Yeah. Thanks, Pedro. So we need to also credential physicians. How much time
do we have? A minute or two? Okay, cool. So this is the hard part. If anyone knows any
companies that can do this for us, we'd love to know. Because once they're credentialed, I'm
mean, that's it. We don't have any way to sort of police them. We need to know that they are who
they say they are, that they have gone to this residency or have had this medical training.
User-friendly interface right now. There's maybe three people in this room who would know how
to do this on this system. So we're going to need to make this interface with a browser of some
sort or an app. If anyone can do that, let us know afterwards. Monetization. We do, we would
like to monetize it. I mean, I don't think we're looking to make crazy profits on this. But
we're looking to make a lot of money out of it. So we're looking to make a lot of money out of it.
There's a few different ways we could do it, but we want to do it in a way that we're not a third
party. It would have to be the sort of thing where the contract is already fulfilled and everyone's
happy and then somehow in some sort of, you know, subcontract or something we're paid
afterwards. We're not exactly sure how we're going to do that yet. The rating system, already
discussed. Go live on Ethereum. We haven't done this yet. So we still technically don't know if
this will work end to end because it hasn't been done on the live network. Okay. I hope we left
time for questions.
Let's get the demo going.
So we're afraid of the, and wow, this is really terrible, terrible graphics. I'm so, so sorry about this.
Let's see if we can zoom in. How do you max zoom in? Max zoom in.
Yeah. And we can make this available afterwards. This is just a video. It's unfortunately
grainy. What this is, and as we sped this up, this is a video of the interaction on the top of an
end-to-end script. The problem with actually doing this, you know, in person is it's something where
I would do something as a patient. Dr.
Would do something. I would do something as a patient. Doctor would do something. And that's
actually going to take hours and hours. Plus the blockchain has to mine everything to verify all the
transactions.
So, so my question is, have you felt of running a, instead of using public blockchain, you can use a
private blockchain, let's say based off on a proof of authority consensus are similar to oracles.org
project that they're trying to do. Um, have you thought of this approach because it's a green
mining, nobody has to, it's like a simplified proof of stake.
Yeah.
So, what he said was right now we're using a private blockchain and it's working. Um, we do wanna
push it out to a public blockchain just to make it so that it's readily available. It's monetized
right there. It's money, right? People pay. Right. People pay in the money.
Yeah, we can do very bad things with this blockchain. So, we wanna make sure that it's verified by
other people. We want to make sure that it's money that people can get, that they, you know,
radiologists can do this thing. They get their ethereum and they get it out of Coinbase.
whatever they needed to do. Alright. Last question. Last question. Okay. So I see you guys
aren't really storing patient information, but you are storing encrypted image data. Yes.
Maybe certain what? Patient information. Would HIPAA apply here? Are you taking that into
consideration that you'd be legally required to do certain things according to HIPAA guidelines?
No. Okay. Enjoy. No, because, because this is, in this case, in all the scenarios we are
putting up here, it's the patient uploading this. With your medical records, you can do
whatever you want. Now, going forward, we would need to get some sort of HIPAA certification
for this. I don't know that it would be a huge problem because once this stuff is encrypted,
it's there in the data store and it's just there. HIPAA is very strong.
So, you know, we're not going to have to construct regulations of how you store it.
I'm familiar. How you audit the server and how you do everything. I violated it a few
times. I'm familiar with it. Yeah, enjoy the fines. Yes, there are heavy fines. So, no, we
see this starting off as a poor man's second opinion to begin with. That would be outside the
bounds of HIPAA. But you're right. Going forward, that would be a problem and a concern. And
not one we're really that worried about because when you start talking about auditability, this
is the public ledger, right? This is the blockchain. So now we kind of know where everything's
transiting. So the data store also supports all kinds of logging that we can do with that.
It's something that we could achieve. I'm not that concerned about it. But to get to the point
where we were proof of concept and it was actually moving data back and forth in an encrypted
fashion, we did not achieve HIPAA compliance today. All right. Cool. Thanks, guys.