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, DEF CON 22, I think, on 9-1-1 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 and this concept, and we
said, heck, let's run with it. So we did this part.
Okay, I already covered most of this, I was just trying to feel like I was going to make a
microphone. This is annoying. If I don't face the camera, is that okay? 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. Oh, no, I'll take this. So over the last, I mean, these are pretty
current, 6 months, 7 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 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 comm built
in, there's no, 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. Alright, so, yes,
this is the obligatory legal language that we have to provide that was developed by
trained ninja JD monkeys. Here, this is just to reflect that this is not necessarily the
opinions or the language, verbage, opinions, 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. Alright, so this is objective.
We did ask for a second microphone. Do we have enough cable to do this or what? Okay. Alright,
so long term we want to improve access to physician care. I mean, that's, that's the big
takeaway 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, I know you all have.
You've all had some weird sore, yeah. I know you all have. Something a little itchy?
You're, you're gross. Um, yeah. So, we think that it'll be helpful to be able to speak over a
secure anonymous platform and say, hey 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, uh, to, to know that. Uh, next
slide. Longer term, and this is what I alluded to earlier, um, right now we have a functional
POC. We're going to show you that today. Um, it's sped up though, so don't think we're
cheating. It takes longer than a minute to do this. It takes like 6 minutes to do this, which
is still pretty good, we thought. Um, so these are the, the key tenets I want you to keep in
mind as we go through this. Uh, 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. Um, 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, uh, I think I maybe broke this
bone or something. Um, but you won't have the internals, so there's still privacy, uh, we, we
hope, we think at play, although we're, we are looking to you guys to help pick this apart.
Uh, next slide. So why Ethereum? Um, you know, it's kind of a, a, you know, a 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 PAC 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, uh, I think they're going to discuss the
security, any chance he or she's in here? No? Okay, well they're going to hopefully talk
about all the, the vulnerabilities in PAC systems that already exist. Um, additionally,
healthcare, the, the costs have become just non-transparent. I mean, we, we think we're
over a hundred dollars to read a, an x-ray, an MRI is probably more, probably a couple
hundred dollars. Um, but frankly that's, that's already too expensive and, uh, we think we
can do better. We know we can do better. Uh, the, the payment system is already built in,
as long as your physician is willing to accept Ethereum. Who here, who in here takes
Ethereum? I think I took a nose dive the last few weeks. Who lost thousands? Yeah, yeah,
sorry buddy. Um, and then, uh, identity management, this is where we really think this
could catch on, um, because how do you know who you're talking to? How do you know this is a
physician? Um, 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 this level, even if he or she is
living in India or even if he or she is living, uh, you know, in Chile or something, uh, which
can also help for 24-7 access to these kinds of, uh, 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. Um, but, uh, you know, we're, we're
hoping that someday we can put together something that allows us to know that this
physician who is credentialed and operating on this, this particular system is not full of
shit. Um, that's kind of where we, 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 a broken, or,
yeah, that probably is what you think it is, that's sore.
Slide. Slide. All right. So, this is me. So, this is the, the architecture, what we
designed, um, to get this done. And 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
blockchain, 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 blockchain. That would be annoying for
everybody. So, we didn't. We ended up using an external data store. 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 that if the data store were compromised, none of the patient
information, specifically imagery, would be recoverable. So, what is passed up there is
public keys and encrypted image data, and that's it. As far as the patient interaction
with the blockchain, that's something where they're sending the payment. They're paying
the physician for that imagery. 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 is 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 blockchain nodes that are operating the
blockchain. 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 arbitrary patient client, we have an arbitrary
doctor client, and we have the data store. And 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
talks on the blockchain. 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. All right. 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 blockchain, 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 blockchain. And for our purposes, we said 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 that's essentially saying, hey, here's something that's unique, 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 ‑‑ 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 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 it 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, 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 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
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 a non-accepted state and it has to be done by the patient. 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 has 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 10 minutes
over a few beers. 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, we don't know that you're talking to a real doctor anymore. And then finally, 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 sit down and, 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 pack system. Slide. Next step. So what we
want to do, um, we, we need to automate more of this. It needs to be, um, I'm not sure what
you meant by checks and balances. So 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, um, 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, the data or on
the blockchain, it'll all error out, but I'd like to tighten that up. Yeah. Thanks Pedro. Um,
so we need to also credential physicians. How much time do we have? A minute or two? Okay,
cool. Um, so this is the hard part. If anyone knows any companies that can do this for us,
we'd love to know. Um, because once they're credentialed, I 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. Uh, user friendly
interface right now. Um, there's maybe three people in this room who would know how to do
this, uh, in this system. Um, so we're going to need to make this interface with a browser
of some sort or an app. Uh, if anyone can do that, let us know afterwards. Uh,
monetization. Uh, we do, we would like to monetize it. I mean, I don't, I don't think we're
looking to make crazy profits on this, but 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. Um, the rating system, already discussed. Go live on Ethereum.
We haven't done this yet. Uh, so we still technically don't know if this will work and end
because it hasn't been done, uh, on the live network. Okay, uh, I hope we left time for
questions. Let's get the demo going. Uh, 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. Um, what this is and was, we sped this up. This is a video of the
interaction on the top of an end to end script. The problem with, uh, actually doing this,
you know, in person is it's something where I would do something as a patient, doctor 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, uh, instead of
using public blockchain, you can use a private blockchain, let's say based off on a proof of
authority consensus or 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 want to 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 want to 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 or whatever they need to do. All right. Last question. Okay. Um, so I see you
guys aren't really storing, um, patient information, but you are storing encrypted image
data. Yes. Maybe certain what patient information, um, would HIPAA apply here? Are you
taking that into consideration that you'd be legally required to do certain things
according to HIPAA? Yeah, why don't you take this one? No. Okay. Enjoy. No, because,
because this is, this, in this case, in all the scenarios we, we are putting up here, it's
the patient uploading this. With your medical records, you can do whatever you want. Um, 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, it's there in the
data store and it's just there. HIPAA has very strict regulations of how you store it and how
you audit the server and how you do everything. I violated it a few times. I'm familiar with
it. Um, yeah, enjoy the fines. Um, yes, there are, there are heavy fines. Um, so no, we, we
see this starting off as a poor man's second opinion to begin with. Um, that would be
outside the bounds of HIPAA. But you're right, going forward, that, 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. It's your data store. 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. Oh!
>>[applause from audience, no audio for the rest of the presentation.