Stream: blockchain
Topic: BigChain
Abbie Watson (Mar 26 2021 at 14:14):
Has anybody else worked with BigChain? Because it stores JSON objects natively on it's chain, it's effectively a native-FHIR blockchain.
https://www.bigchaindb.com/
I ask because I have a Vaccine Wallet app that I'm getting ready to publish, and have a list of people asking about health passports, health ID cards, vaccine cards, vaccine registries, etc. Having worked with Ethereum and Hyperledger, I find their on-chain data model to be way too obfuscated. So, for simplicities sake, I think I'm going to set things up so the users of the app have the option to permanently write their FHIR Immunization records to a vaccine container on BigChain, and call it a registry. Et voila.
Josh Mandel (Mar 26 2021 at 14:35):
What is your goal in encouraging people to write their immunization records to a public registry?
Josh Mandel (Mar 26 2021 at 14:36):
(We've been thinking about proof of vaccination use cases in https://smarthealth.cards, where we give individuals a signed record they can store and use, without having to publish it anywhere. This helps individuals manage their data privately.)
Josh Mandel (Mar 26 2021 at 14:37):
https://vaccinationcredential.org/ has more into on the initiative.
Abbie Watson (Mar 26 2021 at 14:49):
Travel insurance. People lose their phones. Imagine traveling overseas, your vaccine card gets you to some remote local, you have an accident and lose your phone, and now countries are preventing you from getting home because intermediary stops require vaccine approval.
Also, if people posting their vaccine results on Facebook and Twitter are any indication, vaccination is something they willfully desire to broadcast, not keep private. Not for everyone. But there’s an interest.
Josh Mandel (Mar 26 2021 at 14:54):
Re: phones, the expectation is that everything works on paper too, so you can save that. Or digitally you can save a copy of these records in any "online drive" tool.
(I take your point that lots of people are comfortable sharing data publicly, and heck I publish my full medical records on GitHub -- but still, when it comes to packaged, focused apps, privacy by default is super important because defaults drive the "choices" that users make.)
Abbie Watson (Mar 26 2021 at 15:03):
Disclaimer: I find the whole notion of vaccine wallets to be net-neutral in terms of benefits. The research is inconclusive how well they work, and suggests they have the potential for discrimination and reducing social mobility. But... there’s widespread demand, and therefore probably a compelling Patient Empowerment argument that there should be a public/open alternative. And it seems to be a legitimate case for blockchain.
But I’d rather architect and design for positive impact, rather than chase the tech hype cycle. And Ethereum and Hyperledger are so caught up in their own blockchain-ness, with the mining culture and contracts and all, that they can’t take FHIR seriously. Meanwhile, as a dev and operator, I just want something that stores JSON/FHIR natively on chain, and call it a day, ya know?
John Moehrke (Mar 26 2021 at 15:05):
I very much am worried about the elitism that will come with vaccine credentials... but that is a problem that needs to be solved well above the Interoperability Standards level. We need to produce something that works, while outlining all the policy/politics/procedure/etc considerations that are potentiall problematic
Abbie Watson (Mar 26 2021 at 15:06):
YUP.
Stefan Adolf (Mar 26 2021 at 15:09):
Josh, I'd like to second that: there's absolutely no need to put a certificate (aka credential) on any chain. If an issurer signs it, a verifier knows it hasn't tampered with by simply verfying the signature. What you should put on chain (or any trusted, publicly readable, highly read-scaleable, proven to be secure, not controlled by one party, remote "database") is the trust anchorship of the issuer's DID / her public key / signing address. Smart Health Cards are one of the first (imo quite US-biased) good implementations of VC/DID based FHIR-claims I've seen so far. Another might be https://cccc4.ca/ (https://link.getmailspring.com/link/C17092B2-641F-4F68-B289-AAF753E49EAC@getmailspring.com/0?redirect=https%3A%2F%2Fcccc4.ca%2F&recipient=bW0yNjQyOWNiMjNkYTMxZTAyNzdhZDUwZGQwMTMxOWE0MEBzdHJlYW1zLnp1bGlwY2hhdC5jb20%3D) (Canada) or the W3C Vaccination Vocabulary (https://link.getmailspring.com/link/C17092B2-641F-4F68-B289-AAF753E49EAC@getmailspring.com/1?redirect=https%3A%2F%2Fw3c-ccg.github.io%2Fvaccination-vocab%2F&recipient=bW0yNjQyOWNiMjNkYTMxZTAyNzdhZDUwZGQwMTMxOWE0MEBzdHJlYW1zLnp1bGlwY2hhdC5jb20%3D) (~ Europe), both both don't use FHIR.
@Abigail: here in Germany a consortium that builds vacc certs similar to your idea has won the government's call for proposals by March 9 - they're also not storing a certificate on chain but rather merkle tree roots that prove that a credential (which is not bound to an identity but contains PII data to verify a personal id card) hasn't been modified (https://ubirch.de/en/digital-vaccination-certificate (https://link.getmailspring.com/link/C17092B2-641F-4F68-B289-AAF753E49EAC@getmailspring.com/2?redirect=https%3A%2F%2Fubirch.de%2Fen%2Fdigital-vaccination-certificate&recipient=bW0yNjQyOWNiMjNkYTMxZTAyNzdhZDUwZGQwMTMxOWE0MEBzdHJlYW1zLnp1bGlwY2hhdC5jb20%3D)). I'm still 100% convinced that it's a really bad idea to put a certificate (aka a claim about an identity) or only parts of it on an immutable ledger. Sorry to say that, no bad feelings :)
Cheers,
Stefan
Sent from Mailspring (https://link.getmailspring.com/link/C17092B2-641F-4F68-B289-AAF753E49EAC@getmailspring.com/3?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=bW0yNjQyOWNiMjNkYTMxZTAyNzdhZDUwZGQwMTMxOWE0MEBzdHJlYW1zLnp1bGlwY2hhdC5jb20%3D), the best free email app for work
Abbie Watson (Mar 26 2021 at 15:25):
See, I look at that and find it over-engineered. I’ve done the federated/sovereign-ID-on-hyperledger thing before, and vendors didn’t want to support the ID in their FHIR server, because they didn’t control the chain.
Which is why I’m a proponent of ripping out the smart contract overhead, getting back to basics, and following-the-data. We have JSON and XML datatypes, so focus on the blockchain-like technologies that natively support those formats. That’s the path to building FHIR specific chains. Start with something straightforward like Immunization to verify the technology, then use Provenance on-chain to support all the security use cases and bootstrap into the model you’re suggesting.
Aside: we’re going to have QR codes that carry the entire FHIR Immunization resource in the barcode. And a QR scanner in our wallet, so someone can scan another phone from a tollbooth or entry point. QR-on-FHIR is a crazy cool technology. Works better than NFC-on-FHIR, even. Doing the hashed-record-on-chain approach doesn’t let us pop the record off and display it with existing UI.
Abbie Watson (Mar 26 2021 at 15:29):
This conversation does make me think we need a clause in the Terms and Agreements before rolling this out, that we reserve the right to scrap the entire registry and take it down if it doesn’t perform as expected.
Josh Mandel (Mar 26 2021 at 15:31):
"vary the entire FHIR Immunization resource" --> *carry ?
Josh Mandel (Mar 26 2021 at 15:32):
Re: QRs, keeping thing small can be a challenge. Practically these get harder to scan as you get beyond ~V22 symbols. https://smarthealth.cards/#health-cards-are-small is the bag of tricks we use to keep things small FWIW.
Josh Mandel (Mar 26 2021 at 15:37):
(If you're only looking to make this work within your own app, you can also just go the protobuf route, which helps a lot -- it's just a higher bar if you have a diverse set of implementers to bring into the fold.)
Abbie Watson (Mar 26 2021 at 16:24):
Right. We’re probably looking at supporting multiple chains long term. But the politics of the Ethereum and Hyperledger (IBM/Oracle) worlds are just too obfuscated and lost in their own drama. I’m looking for keeping it dead simple with an initial proof-of-concept in production.
Abbie Watson (Mar 26 2021 at 16:33):
Oh, by the way... PatientEmpowerment is taking a vote next week to possibly co-sponsor the Vaccine Card track. We had folks from Europe bring up the European vaccine initiative a few weeks ago, and turns out there’s a fair bit of interest.
Great work on the SmartHealth Cards spec, btw. The cryptography seems both straightforward, but also very liability avoidant at the cost of ease-of-use. I’m reading it in more detail right now, and it seems to advocate that any Vaccine Wallet operator become a notary signer of sorts. Which... I’m not entirely against. But on first read, it seems implementing the spec obligates the implementor into certain business models. Maybe worth spelling out a policy implications section?
Josh Mandel (Mar 26 2021 at 17:19):
advocate that any Vaccine Wallet operator become a notary signer of sorts
Can you say more about this? We basically want/hope the wallet role to be very thin (a user can use a paper wallet with printed cards, or a digital wallet that shares the same content) -- the wallet doesn't "vouch for" anything. Issuers vouch for their content, and verifies can check the content; digital wallets are entirely optional, and when used are only a conduit.
Josh Mandel (Mar 26 2021 at 17:21):
implementing the spec obligates the implementor into certain business models
I hope not, but say more about what you mean? The only requirement is that issuers, if they're going to be compatible with the spec, need to openly host their public keys (i.e., the mere act of validating an issuer's signature on a Health Card can't require pre-arrangement or payments)
Abbie Watson (Mar 26 2021 at 20:13):
Well, follow the data right? Consider some app developer, develops an app which allows the user/patient to select an Immunization record from their Apple Health Records. It's been issued, but there's no JWT signature. Just a JSON blob sitting in their FHIR storage. They pick it up, make a QR code out of it, share it, and the next phone over displays the record. In the following example, they know somebody named Altick Kelly gave Candace a vaccination. That's enough for whatever screener involved to call up Altick Kelly to confirm the vaccination. That's all that's needed. Anything more is a bit extraneous.
IMG_7196.PNG
IMG_5F42D2DBD176-1.jpeg
Don't get me wrong. If we can get Apple and others to support the JWT tokens as ride-alongs, that's gravy. I'm all for it. But as far as the current state of things go, the app developer would need to act as a (re)issuer and assign the JWT, which is what I mean by acting as a notary.
Abbie Watson (Mar 26 2021 at 20:19):
Next step of course, is writing to a ledger somewhere, either permanent or temporary.
Last updated: Apr 12 2022 at 19:14 UTC
