Stream: blockchain
Topic: Blockchain?
Grahame Grieve (May 16 2017 at 09:51):
https://www.tbray.org/ongoing/When/201x/2017/05/13/Not-Believing-in-Blockchain
Abbie Watson (May 16 2017 at 13:44):
I like the skepticism, and think it's well placed.... there's a lot of flakey folks in the blockchain world. Fintech newcomers trying to displace established actors.
But I do think people are going to be able to 'get shit done' with blockchain. At the end of the day, it's basically just a distributed database that can handle smart contracts. And that's a needed technology. The healthcare industry needs interoperability on legal contracts... HIPAA Authorizations, Research Study Approvals, Advanced Directives, Insurance... and blockchain allows a way for that to happen. So the 'get shit done' is likely to be seen in the area of interoperability between legal jurisdictions.
Also, having worked through a prototype, I'm pretty sure blockchain + fhir can provide a mechanism for HIEs to get paid per FHIR endpoint access, and thereby provide viable financial incentives for hospitals to participate in HIEs and pay for underlying infrastructure.
Abbie Watson (May 16 2017 at 13:55):
Also.... would Contract be the appropriate FHIR resource for HIPAA Authorizations, Research Study Approvals, Advanced Directives, and Insurance Policies?
John Moehrke (May 16 2017 at 14:47):
The big problem is the fact that everything in the blockchain must be visible, and health information must never be visible... This doesn't mean there is no hope, but it does highly constrain the usefulness. All the use-cases proposed so far would be far more efficient in a normal database with a nice FHIR API. https://healthcaresecprivacy.blogspot.com/2017/03/healthcare-blockchain-use.html
Abbie Watson (May 16 2017 at 15:10):
PHI doesn't include legal contracts themselves, I don't believe. At least, that's the argument the blockchain proponents are making. Have the legal documents in a public registry with redirects to the regular databases. It's complicated, since the legal documents might infer what kind of care a person is receiving. But if the HIPAA Authorizations are structured correctly, it shouldn't be a problem.
For example "I (Jane Doe) authorize any credentialed physician in the Blue Shield Health Network to access my electronic record during point of care.' versus 'I (Jane Doe) authorize MRI Imaging Associates to access any necessary records for my treatment of breast cancer.' The former would work really well on the blockchain, doesn't violate PHI, could be a public record, and could streamline all sorts of interoperability issues.
Abbie Watson (May 16 2017 at 15:13):
A practitioner would present their credentials to the blockchain, and the smart contract would parse Jane Doe's HIPAA Authorization; if the practitioner has valid credentials, is part of Blue Shield network, and in a point of care, the blockchain would serve up an OAuth token and FHIR endpoint; and the practitioner would go fetch the relevant data.
John Moehrke (May 16 2017 at 15:23):
That use-case is far easier to accomplish with OAuth in User Managed Access form. This is the focus of a joint workgroup hosted by OpenID, UMA, and many from healthcare -- See HEART details https://healthcaresecprivacy.blogspot.com/2015/11/heart-profiles-for-review-comment-and.html
Abbie Watson (May 16 2017 at 16:02):
Sure, if you're willing to have that single point of failure and authorization servers getting out of sync. Don't get me wrong, I only see blockchain as an incremental improvement over existing authorization server architectures. But it does improve the UMA use case. And if the UMA use case is validated by HEART, then the blockchain use case is basically also validated by them. The question is whether the incremental improvements in synchronization, distributedness, and security outweigh the costs of implementation. Having the UMA authorization servers for local healthcare networks manage the block access for state and national blockchains seems like it would make a lot of sense.
Grahame Grieve (Jun 21 2017 at 18:43):
yet another 'blockchain will solve the world':
Grahame Grieve (Jun 21 2017 at 18:43):
http://healthstandards.com/blog/2017/06/20/credentialing-with-blockchain/
Grahame Grieve (Jun 21 2017 at 18:44):
I'm inherently suspicious that a technology will solve a human process problem
Grahame Grieve (Jun 21 2017 at 18:44):
but this does sound like an area with blockchain could be genuinely useful
Brian Ahier (Aug 10 2017 at 18:29):
From MIT: Credentials, Reputation and the Blockchain
http://er.educause.edu/articles/2017/4/credentials-reputation-and-the-blockchain
John Moehrke (Aug 11 2017 at 13:03):
That is a nice use of blockchain... In Healthcare it would allow patients to search for a Doctor with the credentials they want. Or simply to understand the credentials that their doctor holds. We are building this with Provider Directories, but they don't have the crypto proof that blockchain has (although same crypto algorithms can be used in a digital signature model). An interesting 'reputation' addition, could be by patients who received exceptional care (or not); but those would need to somehow be based on some other identity or reputation system so as to prevent ballot-stuffing, harassment, coercion, extortion, shaming, or doxing. The ways a system can be abused must be considered along with the happy-path benefits of that system. The article does recognize this, although not as bluntly. Reputation systems are built on prior reputations..... turtles all the way down
John Moehrke (Aug 11 2017 at 13:15):
is a good explanation for why I would use Blockchain to hold all the Resources that make up my Provider Directory. Use FHIR Resources so that they are structured and coded. Allowing each resource to be widely published, and for this system (the MIT article) to be used for credentials and for reputation.
Jim Kreth (Aug 16 2017 at 21:35):
@Brian Ahier that's a very interesting article and very timely. I'm working on a Common Notifications and Alerting platform for my company and one recent constraint we've been given is to verify the alert recipient's identity and in some cases their credentialing prior to delivering the alerts. One thing I did not see addressed in the article was the revocation of credentials (badges). In addition to regulatory revocation, this might also apply to any credential that had time limits or extended provisions for keeping the credential "active/current" over time. CISSP is a good example.
Grahame Grieve (Sep 13 2017 at 14:23):
https://freedom-to-tinker.com/2017/09/12/blockchains-and-voting/
Grahame Grieve (Sep 19 2017 at 09:44):
can someone explain why this is wrong?
Grahame Grieve (Sep 19 2017 at 09:44):
Grahame Grieve (Sep 19 2017 at 09:45):
I'm thinking about blockchain for audit trails... what if I fed every audit event my server creates into a block chain... a public one.... what block chain? ipfs?
Grahame Grieve (Sep 19 2017 at 09:47):
@Abigail Watson @Doug Bulleit @Brian Ahier @John Moehrke the hype around blockchain is growing geometrically, but I'm completely unconvinced. Still.
Grahame Grieve (Sep 19 2017 at 09:47):
so comments are welcome...
Doug Bulleit (Sep 19 2017 at 11:29):
Like all good hyperbole, both the conclusions as well as the topic of this article are IMHO overstated.
Back in the dot-com era, pundits were claiming that the looming internet was about to change everything! All [sic] that it ended up doing was to remove much of the friction, and many of the intermediaries, involved the business of information transfer. Similarly, much of the hype around blockchains misses the point of its true potential--i.e., to remove much of friction, and many of the intermediaries, involved in the business of value transfer.
IMHO, blockchains are unlikely to have dramatic impact upon FHIR itself; that said, by adding a potent layer of improved Trust, they could dramatically accelerate its proliferation and application business models.
While some of the arguments the article's' author makes about permissionless (e.g., crptocurrencies) and private (enterprise-bound) blockchains have merit, his neglect of another variation--i.e., permissioned (inter-enterprise) blockchains--betrays either a shallow understanding of the topic, or an agenda, or both.
Shortly, we'll be coming forward with a concept now being worked through the Linux Foundation's HyperLedger Project: one that may prove important to FHIR app developers interested in higher levels of security and higher levels of patient engagement. In the interim, I'd be happy to discuss this idea with anyone on this board
I can be reached at Doug@FHIRBlocks.org
Grahame Grieve (Sep 19 2017 at 11:53):
so can you expand on inter-enterprise chains? do they use mining? or work around it another way? if so, how?
Doug Bulleit (Sep 19 2017 at 12:11):
I'd be happy to! How/where would you recommend as the most efficient way (as a full discussion of "Permissioned" blockchains can get complicated quickly) e.g., your specific question regarding consensus/validation can have more than one answer. IMHO, one way to get immersed in this topic would be through HyperLedger's healthcare Working Group in general and the FHIRBlocks Project forming within that same WG.
Grahame Grieve (Sep 19 2017 at 12:12):
well, you could give me a few paragraphs here - I'm just not going to have time to participate in yet another work group
Doug Bulleit (Sep 19 2017 at 12:29):
OK. Actually, it's a multilevel discussion. At the bottom, a blockchain is nothing more than a comparatively inefficient DBMS. What makes it interesting is its true P2P nature: one that insures that any adds/changes to it are locked in cryptographic stone and that there's no central server for anyone to control. An assortment of consensus/validation methods--e.g., proof of stake-- are available to permissioned peer/nodes that jettison energy & time-intensive POW/mining. From there, an assortment of micro-app's resident in the distributed blockchain DBMS enable all sorts of innovative processing of the stored data (e.g., fine-grained & conditioned access permissioning to resources kept elsewhere). Yet another interesting "layer" of such an architecture involves how it can support self-sovereign identity management.
Anyway, this is a start; `more to follow in the FHIRBlocks Project
John Moehrke (Sep 19 2017 at 12:41):
Grahame, a public block chain does need to use a proof of work model. Thus it is rate-limited, which will be stressed by audit log volume. A public blockchain will also need to be clear about what the miners have validated. In bitcoin the miners validate everything, there are no secrets. In a healthcare audit log, there will likely be much that needs to be kept private. Such as patient identity, provider identity, data content, etc.. One could put an AuditEvent on a chain, and just ask the miners to simply timestamp-signature. Thus proving only that the AuditEvent existed prior to the timestamp on the block it exists within.
Grahame Grieve (Sep 19 2017 at 12:42):
ok thanks. I'll have to invest in some time with these partial validation solutions
John Moehrke (Sep 19 2017 at 12:43):
Private blockchains don't need to use proof-of-work, but do need to have a defined 'work' that miners do. This work does need to have some value. This keeps overhead smaller, validation usefulness larger, and scale tuneable.
John Moehrke (Sep 19 2017 at 12:45):
I did like the observation that Keith made on blockchain, relative to scale of bitcoin vs scale of healthcare. https://motorcycleguy.blogspot.com/2017/08/four-reasons-why-blockchain-isnt-next.html
Doug Bulleit (Sep 19 2017 at 12:49):
John
IMHO labels are important here. In contrast to my understanding of your points, the article that started this thread described "private" blockchains as enterprise-bound. The nuance of inter-enterprise (but non-public) "permissioned", therefore, may be a more useful label here. In other words, we're not talking about permissionless/public blockchains here; and IMHO that renders most for the "snake oil' arilce irrelevant.
Abbie Watson (Sep 25 2017 at 02:16):
I'm thinking about blockchain for audit trails... what if I fed every audit event my server creates into a block chain... a public one.... what block chain? ipfs?
One would probably want to keep the list of Organizations that participate in the blockchain on IPFS. As a swarm filesystem, it would be responsible for syncing the authoritative copy of who's one the blockchain or running DApps that access the blockchain. IPFS is a good candidate for synchronizing data dictionaries in general... think annual updates to CPT, HCPCS, ICD-*, insurance plan coverage changes, current physical locations that a healthcare network is providing services at; etc. That's all excellent data to put on IPFS.
A good way to think about blockchain is in terms of capacity planning. The Ethereum ecosystem is growing at about 1GB/month, and as of last year was about 75GB. So it's probably at 85GB to 90GB now. Which includes every Ethereum financial transaction. That's relatively small.
If one is going to log every audit event onto a blockchain, the chain would need to be hospital specific. One would just need to set up multiple chains. So MayoClinicChain, CookCountyHospitalChain, RushMedicalCenterChain, and so forth. Which might work fine for IoT medical device needs in a hospital, and solve that particular problem.
On the surface, this would seem to be prohibitively expensive (i.e. 'cumbersome database'). But it's possible to dial down (or up) the cryptographic strength to make the mining go faster. So 192bit chains might work just fine for IoT chains running in a hospital and resolve inter-hospital device interoperability - and be more cost effective than 256bit chains.
Alternatively, I find the Blockchain HIE usecase much more interesting. Where an insurance company runs the blockchain, and stores smart contracts on the ~1GB/month storage. The smart contracts are then used to resolve ACL lists. Just run the blockchain as an additional service to existing identity services like Active Directory, LDAP, etc. Once ACL lists are resolved, then endpoints are queried from the Organizations stored on the IPFS swarm, and resolve the audit events from the local institution using FHIR.
I agree with Doug - blockchain won't impact FHIR itself, but may be a driver for increased adoption of FHIR. If there are trust services being offered via blockchain (i.e. insurance plans, health information exchanges), and the requirement for participating in the blockchain or insurance plan is to use the FHIR standard.... well, that will drive adoption real quick.
Grahame Grieve (Sep 26 2017 at 06:08):
Brian Postlethwaite (Sep 27 2017 at 02:30):
So just processing claims data in the blockchain data? Is that claim data secure on the linux foundation hosting?
Tony Little (Oct 12 2017 at 21:55):
Brian, there are a number of ways this could be done with current blockchain technology. Hyperledger has a few releases of blockchain software, the one we are using is Fabric. (https://hyperledger-fabric.readthedocs.io/en/latest/) I don't think that they actually offer blockchain as a service (like IBM does). If you use Fabric in a private / permissioned setting model then it could solve most of security concerns but possibly not all. There are some encryption-at-rest and transaction payload visibility concerns that exist that could turn off enterprises that are on the extreme risk averse side. Ironically, SawTooth (https://www.hyperledger.org/projects/sawtooth) solves some of these concerns but does not have a number of features that make Fabric desirable. So to cut this short, the tech is getting closer every day and there are a few use cases, like provider credentialing, that can be tackled today - even partly on a public chain like ethereum.
The consensus from my research is that unless you can figure out the economics of blockchain there is not significant benefit over a traditional database. This can start by working the technical side as POC/Pilot, but the business value will be elusive unless you get to strong network effects, which as we know a lack thereof is why 99% of networks die. To get the network effects you need the right incentives. Read this to get the story from both sides (math & economics). https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2874598
There was a comment above (some time ago) about the ethereum team and a seeming disinterest in healthcare but I would argue that if you try to make enterprise blockchain the end-goal, concentrating only on the cryptography, you will be disappointed and someone will get tired of paying for the network. That may have been why there was a seeming "dismissal" in the discussion with the ethereum community. The argument could be: "Why build out costly, centralized infrastructure when we could better focus our time and energy by making public chain better suitable for healthcare?"
Grahame Grieve (Oct 19 2017 at 23:16):
https://blog.chain.com/a-letter-to-jamie-dimon-de89d417cb80
Peter Jordan (Oct 20 2017 at 02:50):
Are you convinced by the 'censorship resistance' proposition, particularly in relation to healthcare data?
Doug Bulleit (Oct 20 2017 at 20:09):
At the very end of this meandering, but interesting, BLOG was an allusion to an entirely different aspect of distributed (a.k.a., block-chain-enabled) App's: i.e., private/enterprise (a.k.a., permissioned) ledgers. `look for more, and more interesting, new trust models--networks that IMHO could dramatically expand FHIR's influence--in the weeks to come
Grahame Grieve (Oct 20 2017 at 22:34):
I'm not sure what role anti-censorship has to play in healthcare. Maybe the anti-vaxxers will claim that they are being censored, and believe that this is a compelling use case. Otherwise... where is the need?
Doug Bulleit (Oct 21 2017 at 00:52):
IHMO it's important to view blockchains for both what they are not as well what they may enable. There's no use case that I know of that can't be more efficiently supported on a centralized architecture. But, centralization implies a central entity in control, not to censor but to restrict information to applications and/or to subordinate their business models. EHR Resources and FHIR-enabled App's themselves probably should NOT be shoe-horned into a blockchain. But the new Trust models, that higher-trust and self sovereign permissioning of authentication & authorization (of both innvative new app's as well as the Resources that enrich their value), may write a different open network story (with FHIR in a staring role!).
Doug Bulleit (Oct 21 2017 at 01:34):
`just after hitting send on the previous post, this one came across my screen: that eloquently speculates on a blockchained future of distributed FHIR-enabled App's. Moreover, it also alludes to the pivotal role of self-sovereign [patient] identities https://health2con.com/news-iteam/8992/
Lloyd McKenzie (Oct 21 2017 at 03:25):
It also claims that with no central authority block chains can be quicker, easier and cheaper. Even blockchain models with a central authority tend to be slower and those that require "proof of work" are much slower/more expensive than traditional database models. It's not clear what block chains can do for patient control that a patient-controlled PHR or patient-controlled secure phone repository couldn't do more efficiently.
Doug Bulleit (Oct 21 2017 at 05:19):
(deleted)
Doug Bulleit (Oct 21 2017 at 23:49):
Well, here's but one way that a permissioned off-chain OAuth supplement may widen FHIR's potential universe while, at the same time, narrowing its exposure to fraud and cyber attack: it involves an emerging blockchain faculty known as self-sovereign identity management . And its practical impact could be to effect the equivalent of a strong client-side digital certificate
Grahame Grieve (Oct 22 2017 at 10:42):
elsewise, the focus is on the permissioned ledgers, though I personally don't think that the block chain is the most efficient solution as soon as you accept a central point of control
Grahame Grieve (Oct 22 2017 at 19:41):
@Doug Bulleit
But, centralization implies a central entity in control, not to censor but to restrict information to applications and/or to subordinate their business models
Can you expand on what you think the difference between 'censor' and 'restrict' is?
Grahame Grieve (Oct 22 2017 at 19:44):
I read Matthew's blog, but it didn't actually tell me anything. what use of blockchain in healthcare can do something useful without having to have the highest level of proof-of-work?
Doug Bulleit (Oct 22 2017 at 21:00):
(deleted)
Doug Bulleit (Oct 22 2017 at 21:04):
Can you expand on what you think the difference between 'censor' and 'restrict' is?
Fair question. While I wasn't implying any sort of formal semantic difference, there is a bit of business model nuance behind the thought. And, continuing upon the allowance that "central control is always more [IT] efficient ,BUT...", part of the motive driving permissioned blockchains (where all nodes are known and, more-or-less, trusted by one another) is the idea of a neutral platform: one where no mutually-sanctioned participant can unilaterally "censor or otherwise restrict" the flow and use of Resources within the emergent ecosystem (beyond, of course, an agreed set of TOU rules). Moreover, with a means to establish strong "self-sovereign" Trust within their digital wallets, users and application providers alike can enter and exit such a network without necessarily being subordinated to any particular EHR platform/regime. Finally, "strong POW" is not required within a permissioned blockchain that is properly configured and operated. I gather that [Mathew or Adam?] will cover that in a subsequent BLOG installment?
Doug Bulleit (Oct 22 2017 at 22:15):
I have no idea why the Reply above is appearing in the scroll box as it is. `apologize for the poor communication skill;-) Pleas advise on how to fix
Grahame Grieve (Oct 22 2017 at 22:32):
it's because you used ``` - that's a sign to zulip to treat what follows as code and not to wrap it
Grahame Grieve (Oct 22 2017 at 22:35):
so if you are using block-chain to establish control-point independent management of permissioning of healthcare information, won't that require absolutely the highest level of crypto-integrity? And how will monitoring that public good, which is not associated with a profit, not collapse down to a single point of control?
Doug Bulleit (Oct 23 2017 at 00:37):
Thanks for the Zulip tip; not your job but much appreciated
Yes the open-source SMOAC (Supplemental Method of Open Access Control;-) protocol that we're developing, to overlay OAuth2/OIDC, employs EdDSA: (an even higher cryptographic standard than the TLS methods that it is overlaid upon). Plus, the fine grained permissions and self-sovereign attestations coded into the permissioned blockchain's smart contracts are all individually hashed; thus, not only is the would-be hackers' job harder, but the much-narrowed attack surface becomes so small as to make the value of the de-minimis targets fall to near zero. Here's a draft of but one in a series of charts that we're preparing to more fully introduce the concept to you and others. And, we're proposing, that the value of the improved security and business flexibility, combined with the relatively small incremental cost of operating a permissioned node, will induce IDN/health systems and AppStores to absorb assocciated costs.Untitled.png
John Moehrke (Oct 23 2017 at 15:03):
I am not clear.. The concepts of non-censor only work with an open blockchain, which has no way to hide an entry in the block, which thus is a problem for healthcare data... However a permissioned blockchain has this encryption, but once there is 'permissioned' and/or encryption; then one can censor... It seems two different solutions are being talked about as if the solution gets to take the best parts of both solutions; but they are mutually-exclusive.
Doug Bulleit (Oct 23 2017 at 15:26):
Why (are they mutually-exclusive)? If you assume that the Resources themselves are always off-chain (behind the FHIR Resource server, before being hashed and encrypted for transport to the permissioned App instance), all that appears in the private/permissioned blockchain itself is a pseudonymously signed patient permission, indelible record of every transaction of it, and the smart contract that constructs the discrete OAuth access token (for the self sovereign App to present to the FHIR server)
Doug Bulleit (Oct 23 2017 at 15:39):
Saying all that another way, the paradigm shift that we hope that our forthcoming open source SMOAC protocol will enable is to make the certified/self-sovereign Patient herself as the exclusive "censor" of her own PHI (or, more precisely, the only agent able to uncensor access her own PHI via fine-grained permissions within specifically permissioned App)
John Moehrke (Oct 23 2017 at 16:17):
That is a very different description than you were giving before. I now have the question of how this is better than OAuth/UMA/HEART? Those don't have any of the overhead of blockchain; and you already recognize the authorization decision will be made by OAuth... In these cases there is a self sovereign choice by the patient as to which HEART service they trust, and they impose that trust upon any data custodians. The patient is then fully in-control of the policies that HEART service manages/asserts. The richness of those policies is no greater/lesser capability than any authorization server regardless of policy source (we are all being held victim of the OAuth scopes standardization). So, from what I understand you to say, I see nothing but technology-for-technology-sake overhead. I acknowledge that it is buzzword rich. Am I missing something?
Doug Bulleit (Oct 23 2017 at 18:59):
I believe so (on missing something) and curious about how/why you see a difference in the cryptic descriptions(sorry for the pun, `couldn't resist;-). The main "difference" IMHO involves the substitution of hierarchical enterprise and provider-centric control with a low overhead permissioned blockchain to enable a flat inter-enterprise architecture enabling a more patient-centric App developer ecosystem.
Anyway, we are, in fact building on top of OAuth/HEART/UMA; but in a way that captures Patients' (and other users') App-specific permissions in a shared (but not centrally-controlled) ledger. In this way we hope to enable a subtle (but we think profound) paradigm shift in who/where "authorization decisions" and authentication is controlled--i.e., one where the FHIR server will still see an OAuth token as "authoritative", but the actual author of the fine-grained permissions themselves will be the App/User (not necessarily EHR vendors). There's a lot more, of course, going on behind the scenes here--e.g., more rigorous logon/authentication, how certified self-sovereign identities assume a virtual UPI translation ability (to health system-specific MRN/MPI's), side-chains to complimentary app/services (e.g., claims processing/payments), and others. But, I think, you get the idea...
Doug Bulleit (Oct 23 2017 at 19:04):
In any case, we're now writing the SMOAC protocol to a repository in GitHub and hope to publish it in open source fashion in the HyperLedger Project within the next few weeks. And, I suppose that it goes without saying (but I will anyway) we would be truly honored to have you and others within the FHIR community as contributor/commentors
Doug Bulleit (Oct 23 2017 at 21:00):
quote
"I now have the question of how this is better than OAuth/UMA/HEART?"
John: to your question on HEART: attached is chart from it s WG Intro deck. The SMOAC protocol focuses upon the same topics (with particular emphasis on FHIR Resource mgmt); but it's real contribution (we hope) will be on augmenting HEART with solutions on the last two bullets
pasted_image_at_2017_10_23_02_50_pm.png
Anyway, thanks for your time and attention as, without it, we can't make our explantion (let alone our solution) better
Last updated: Apr 12 2022 at 19:14 UTC
