Stream: blockchain
Topic: Challenges with block chains
Grahame Grieve (Dec 12 2017 at 20:07):
https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428
Peter Jordan (Jan 09 2018 at 07:30):
The 'overall vision' paragraph (#2) in this article is certainly challenging - from a credibility viewpoint...
https://www.linkedin.com/pulse/why-blockchains-transform-healthcare-bernard-marr/?trackingId=h2mrdoNLEQtbcd0qQfIEMA%3D%3D
John Moehrke (Jan 09 2018 at 13:18):
The overall vision is a useful overall vision for all working in HealthIT. I find nothing new in the article. I guess I should rewash some of my old blockchain articles to get some clicks...
Doug Bulleit (Jan 14 2018 at 13:45):
IMHO the problem with so many blockchain discussions, particularly healthcare-related ones, is that they aim to disrupt too many extant systems and processes too quickly; thus, they get no real traction. Even FHIR's own heroic efforts to move EHR into the 21st century seem to combat status-quo headwinds that they don't really deserve. That said, a few, more incremental, proposals may slip in a bit earlier than expected. For example, even as it approaches a normative standard, FHIR will still face inter-EHR interoperability challenges. Could permissioned blockchain-enabled dAAA (decentralized Authentication, Authorization and Administrative domain management extensions upon OAuth2) point the way to more dynamic, effective and economical HIE?
Grahame Grieve (Jan 14 2018 at 19:46):
well, you'd have to explain how the issues that make inter-EHR interoperability a challenge are in any way addressed by a non-tamperable public ledger.
Doug Bulleit (Jan 15 2018 at 01:47):
I'd be delighted: to take a crack at briefly outlining a way that distributed ledger technology [DLT] may address certain inter-EHR challenges.
First, we need to stress that the open-source protocol being developed under the banner of FHIRBlocks* directly effects neither PHI nor various other FHIR Resources (e.g., profiles, scopes, contexts, tags, etc). Rather, it deals with the always-difficult problems of private-virtual AAA (open network authentication, authorization & ddministration) in general and inter-enterprise trust in particular. It starts with privacy & security and moves up through real and perceived end-user confidence, control and engagement. Specifically, the smart contracts contained within a permissioned blockchain can facilitate, among other things, DLT removal of centralized honeypots (e.g., conventional OAuth2 servers) while directly involving certified self-sovereign end-users themselves in higher-trust authentication, authorization and fine-grained Resource access permissioning/sharing over multiple EHRs, care providers, managers and others.
I'm afraid that this may be a bit too tightly packed nutshell; but, I'd be happy to elaborate over a more appropriate format at your convenience.
___
- FHIR remains, of course, HL7's registered trademark
Grahame Grieve (Jan 15 2018 at 09:50):
Honestly It all sounds like word salad to me. How does it actually work?
Doug Bulleit (Jan 15 2018 at 14:12):
As I said, it's a bit much to cram into a single paragraph. But, the way it "actually works" is this: the OAuth2/OIDC server is virtualized within a permissioned blockchain nominally comprising nodes operated by each participating health systems', or IDNs', EHRs. Moreover, the peer-to-peer IDNs can then allow their various users to create self-sovereign identities on the blockchain wherein inter-system and multi-user permissions can be irrefutably established. These fine-grained permissions, in turn, operate within smart contracts that are able to generate access tokens available to the permissioned Apps on demand.
hope that helps
Lloyd McKenzie (Jan 15 2018 at 16:01):
So the EHR systems are expected to externalize both their user-identification mechanisms and the logic that determines who's allowed to see what? That doesn't seem like a near-term winner to me... I'm also having trouble wrapping my head around the notion of a public ledger of either users or their permissions given that both are private information.
Doug Bulleit (Jan 15 2018 at 16:46):
Lloyd, thanks for the clarifying question & comment. The aim of FHIRBlocks is NOT to "externalize user identification [nor authorization/admin] mechanisms." Rather it is to virtualize them on a more secure private peer-to-peer/common ledger, thus facilitating inter-EHR interoperability and multi-user collaboration. Moreover, it's built upon standard OAuth/HEART methods: methods that, left to their own devices, arguably externalize some of these functions already (but in a demonstrably less-secure manner). Your point on self-sovereign users, empowered to participate directly in the access permissioning process, is also well taken; and IMHO it's a development with interesting implications worth careful consideration in this forum
Lloyd McKenzie (Jan 15 2018 at 18:35):
I'm trying to understand what's private from whom. Who has access to the list of users? Who controls access to that list? Who controls access to the permission rules?
Doug Bulleit (Jan 15 2018 at 18:53):
Good questions Lloyd. Really! Indeed, the nuances between what's permissioned/permissionless vs. what's private/public vs who can read/write/validate into a blockchain goes to the heart of a lot of confusion and arguments that are also occurring in other DLT circles.
Fortunately we don't need to resolve all that to begin answering your questions
The forthcoming and open-source FHIRBlocks protocol provides for a permissioned (private) blockchain wherein participating IDN nodes validate transactions (e.g., RESTful data transfers and AAA signals) in near real-time and allow IDN-selected App's to read the ledger; and, where/when appropriate, App's can then request JWT access tokens. Apps write to the ledger only for admin/audit purposes (any/all read/write to FHIR servers themselves of course remain under FHIR protocols' control). Under certain carefully controlled circumstances, Users can both read and write to the common ledger--e.g., to establish certified self-sovereign identities and to participate in the granting and management of 3rd-party access permissions.
One last point: in addition to TLS on all data transmissions, Users' PII (outside of any FHIR Patient Resources) is fully psuedonymized and transactions are all hash coded into the DLT
Hope this helps.
Lloyd McKenzie (Jan 15 2018 at 22:41):
hope that helps
Not really. Lets start just with users and forget everything else. Who can write to the chain? Who can read from the chain? What can those who can read see? Who are the trusted parties who "host" the chain and thus ensure that we don't need the expense of proof of work?
Doug Bulleit (Jan 15 2018 at 23:37):
OK. Thanks for helping frame the issues.
The actors here are the actual End-Users (patients and/or care-providers represented in this DLT by certified self-sovereign Identities, or CSI's (held within Users' digital wallets); the App running on their mobile devices; the permissioned Blockchain itself; and the FHIR Servers.
In order of your questions then...
1) Apps, bound to and signed by registered CSI's, can write certain permissions into the Blockchain pursuant to certain interactions with End-Users
2) Registered App's can read from the Blockchain (to query it for CSI/App-specific permissions) and/or to request access tokens to permitted Resources (to be remitted to appropriate FHIR Servers)
3) App's can read CSI-specific permissions (note that CSI's are pseudonymous; thus the App cannot directly identify real names of Users); different App's can also read the Blockchain's Merkle Trees (to review/confirm previous transactions)
4) Light-weight nodes (that may eventually be integrated into FHIR Servers and/or provided by proxy) within the EHRs and other "trusted" peers on the Blockchain, validate transactions using a non-POW consensus protocol (e.g., Linux/HyperLedger's RBFT method)
Let's keep this Q/A going!
Lloyd McKenzie (Jan 16 2018 at 00:48):
Ok. So each patient and each practitioner needs to have a digital wallet. Is that like an apple wallet or do they need to install a special app? You jumped into permissions. I don't care about permissions yet. Lets just focus on user identity only. Is user identity written to the block chain? By whom? How is user identity verified? What information can systems see about users? Do users need to trust all of the EHRs involved as block-chain validators? What other "trusted" peers do you anticipate and who decides that they are "trusted"?
Doug Bulleit (Jan 16 2018 at 01:06):
Terrific questions...thanks again!
As you know, self-sovereign identity mgmt is a complicated topic onto itself; and, for my money (pardon the pun), it may emerge as a more pervasive blockchain App than cryptocurrency itself;-)
Now, back to your questions...
1) In fact, our current POC implementation is built entirely upon a forthcoming extension on iOS' UDID PassPort (though Android and Windows equivalents are planned)
2) There's a smart contract facility in the blockchain that assists the User configure a FHIRBlocks wallet; but, the CSI (identity itself) resides in the wallet (though we're alos planning a uPort-like key/wallet recovery mechanism which could involve DLT- identified "trusted witnesses"
3) Another smart contract facility creates the full equivalent of a client-side digital certificate . It accomplishes this through "verifying" interactions with 3rd-party information bureaus working in conjunction with the Health Systems' own MRN (and perhaps FHIR Patient Resources?).
4) FHIRBlocks expose no personal information to anyone, including EHRs; to the extent to which the App itself is empowered to reveal information is beyond FHIRBlocks' scope
5) Users need not trust anyone (beyond perhaps their own care providers); indeed, FHIRBlocks could produce detailed reports on resources consumption. Validators validate pseudonymous transactions; thus, they cannot reveal user information that they can't otherwise identify
6) Other trusted peers could include payers, regulators, CIN/ACO adminstrators, etc. But, again, this is more a governance than a technical question.
Keep 'em coming!
Grahame Grieve (Jan 20 2018 at 05:48):
well, I'll ask then. What would I have to do on the server side to buy into this eco-system?
Doug Bulleit (Jan 20 2018 at 14:20):
As we've discussed previously, there are perhaps larger non-technical/business aspects to these questions: questions that, frankly, we've yet to rejoin fully. And, if I may, I'd like to take a crack at your instant question along with a closely related one.
First, on the technical side, presupposing the IDN's (or health system's) EHR/IT dept has deployed its own FHIR Adapter (or server), minimal adjustments are required--i.e., to equip it to accept OAuth/FHIR-formatted authorization tokens from an alternative source (in FHIRBlocks architecture, from smart contracts contained in a permissioned blockchain).
Where the picture grows a bit more murky is when the IDN/IT staff needs to turn to their legacy vendors to make an adjustment that's not on the vendor's own product roadmap.
And that, of course, brings me to the second half of my incomplete answer: how does something like FHIRBlocks lay down with various stakeholders' business interests?
Depends, I think, on the "stakeholder." To me it's a bit ironic that we have to ask how interested the royal "we" really are in broadened interoperability (let alone prospective cost savings). But we do. And it's not unprecedented! Most other vertical industry segments have all gone through their own resistance to shared network economies and full inter-enterprise connectivity. And the friction in that pervasive migration has also always been, more-or-less, the same: Trust (in its multi-layered manifestions) or more-specifically, lack of Trust beyond one's own Administrative Domain. Heathcare's own somewhat higher Trust thresholds have left it somewhat behind the web services/eCommerce curve.
FHIRBlocks' business bet, then, rests upon three things: first, the demonstrably P2P Trust that permissioned blockchain technology can bring to inter-enterprise networks; second, the superior economics that a common Administrative Domain brings (vis-a-vis centralized hierarchical HIE-like alternatives); all coupled with an exponentially growing pressure to enable inter-EHR application support (e.g., ACO, CRO, CIN, CHR, IoMT, etc)
FHIRBlocks greatest risk then IMHO has less to do with its technology nor the inevitability of its (or its equivalent) architecture. Rather, like the barons of enterprise networks before it (e.g., SNA, intranet/routers, MNS, etc vendors), the question is how long they can hold the status-quo? Clearly FHIR's current DTSU state doesn't necessarily demand this natural evolution happen in 2018. But, what about in its post-Noramative Standard state beyond?
Grahame Grieve (Jan 20 2018 at 19:13):
" minimal adjustments are required--i.e., to equip it to accept OAuth/FHIR-formatted authorization tokens from an alternative source" - which are what exactly?
Grahame Grieve (Jan 20 2018 at 19:13):
on the subject of the economics... it will be a long game...
Doug Bulleit (Jan 23 2018 at 04:17):
OK. I'll try to give you as detailed summary as this space allows (if you like, I can also give you direct access to the (private) GitHub Repo for the actual code?)
First, as stated previously, FHIRBlocks has no direct interface to FHIR Apps per se; rather, it assumes that the App's run on User devices and that Resources all remain "off-chain" (behind the EHRs' FHIR servers). Moreover, the current implementation builds upon HEART and presumes that the FHIR server has been implemented upon RFC-6749 compliant AOuth2 libraries.
That, in fact, could be considered the short answer to your question. But, presupposing that you'd like further detail, here's how FHIRBlocks' SMOAC (Supplemental Method on Open Access Control) works.
Generally speaking, the steps are...
1) Application retrieves the authorization token from an HTTP request to the FHIR Server. Note that the token has three parts: header, body, and signature
2) Smart Contract (SC) running within the permissioned FHIRBlocksChain (FBC) validates that the JWT body has been properly signed. This is performed using an ECDSA signing algorithm, and may be validated with the knowledge of the FBC nodes’ public key (each node possess a key)
3) SC examines the body to determine whether/how to answer the call. Within the body, are base permission information as well as a Certified Self-sovereign Identity (CSI) of the original grantor of permission.
4) The body also contains HEART specific information (this is where "fine-grained permissions" begins), specifically:
a) Which resources are allowed to be accessed: Patient, Encounter, etc
b) What level of access to the permissions is allowed: read/write, both
c) The confidentiality level permissioned: this is a HEART specific concept: refer to that doc for details, and is one aspect of “fine grained permissioned”
d) Which sensitivity levels are permissioned: things like STD information, celebrity info, pysch, etc.
For further detail, consult HEART docs. The FHIR implementer is left to his own devices, per HEART, to determine how this should be implemented within the App
Doug Bulleit (Jan 23 2018 at 04:19):
Also, FWIW & IMHO, any number of market and regulatory forces could accelerate inter-EHR FHIR timeframes
Lloyd McKenzie (Jan 23 2018 at 05:08):
And anyone with access to the chain would thus have access to the smart chain and thus know what users had what permissions to access which patient's data down to a fine-grained level of detail?
Doug Bulleit (Jan 23 2018 at 05:48):
Not really. First, it's a permissioned blockchain ,only registered Users/App's have access to read it; and, only EHR nodes can validate writing. More importantly, however, is the fact that not only are all transfers double encrypted, self-sovereign user ID's are all pseudonymous; thus, only correspondent end-points can know real identities (and, in some cases, not even they can)
Grahame Grieve (Jan 25 2018 at 13:36):
so the FHIRBlocks part is actually all private to the AS in the heart scheme? the RS is not related - that's how I read that
Josh Mandel (Jan 25 2018 at 14:33):
@Doug Bulleit can you clarify which HEART profiles you're building on? ("vanilla" OAuth or UMA?) I'm still having trouble following.
Doug Bulleit (Jan 26 2018 at 04:31):
so the FHIRBlocks part is actually all private to the AS in the heart scheme? the RS is not related - that's how I read that
Yes, I think (but not sure) we're together; the FHIRBlocksChain (a privately*-configured HyperLedger) does not handle Resources nor does it directly interface the FS. It's all about virtualizing the AS so as to accomplish two things: first to provide for common (inter-EHR) permission management; second, to directly involve "self sovereign" patients in establishing certian permissions themselves ( aka self-authorization)
*There's a somewhat confusing difference between a public/private axis running normal to permissionless/persmissioned. But we can take up teh nuance on the 2x2 that that strikes another time;-)
Doug Bulleit (Jan 26 2018 at 04:38):
@Doug Bulleit can you clarify which HEART profiles you're building on? ("vanilla" OAuth or UMA?) I'm still having trouble following.
Yes, for the time being we're using only standard "vanilla" (so far not found much market traction on UMA). Plus, it's also possible that some App Developers my choose to authorize at a very-fine grained Resource-by-Resource level. Current POC supports either, but we still have a lot to learn about how the developer community best meets Patient/IDN/EHR needs
Grahame Grieve (Jan 26 2018 at 09:10):
ok. so i think I'm getting a feel for it. Why is it called "FHIRBlocks"? What's FHIR specific about it?
Doug Bulleit (Jan 26 2018 at 12:39):
Good question! (As would be `why do we need a blockchain anyway? ) And the answer is that FHIRBlocks would work on any standard and widely accepted API; but, FHIR is likely to be the best (if not the only) game in EHR town.
What FHIR may lack is inter-EHR/multi-user Trust: more specifically, inter-enterprise AAA (authentication, authorization & administration) capabilities. IOW, network Trust that spans multiple administrative domains brings different requirements: functions that ordinary OAuth2/HEART can't accommodate. Thus, a permissioned blockchain can provide a common P2P (in several senses of that word) permissioning and proving platform.
Doug Bulleit (Jan 26 2018 at 16:57):
And, as I've noted previously, emerging inter-heath-system agenda( e.g., ACOs) could induce earlier adoption of a more inter-enterprise-capable FHIR
Last updated: Apr 12 2022 at 19:14 UTC
