Stream: blockchain
Topic: The Potential for Blockchain to Transform EHRs
John George (May 28 2018 at 18:28):
Hi All, I am trying to work out how much progress has been made using #Blockchain for EHRs. since this paper was written a year ago: <https://hbr.org/2017/03/the-potential-for-blockchain-to-transform-electronic-health-records> by John Halamka et al. #Blockchain looks like it has the potential to standardize secure data exchange, however I've heard some arguments suggesting it is unlikley to be a success in England's NHS, because of the nature of the SPINE, so it's centralized vs. decentralized enviroment that #Blockchain seems to favour. I should clarify, I'm new to the world of #Blockchain, so I am more than happy to be educated on this topic, via further discussion.
Grahame Grieve (May 29 2018 at 12:56):
blockchain is useful when you don't trust the administrators for various reasons. I fail to see how this is relevant to standardizing secure data exchange
Adrian Lanzafame (May 31 2018 at 02:39):
The only valuable role I see a blockchain playing in data exchange, is as a form of proof that two parties did in fact exchange data. An example from the Australian context, being able to verify that a lab did send a patient's results and that those results made it through the SMD intermediary, and arrived at the appropriate destination would be extremely valuable. Granted the system wouldn't look like that if blockchain was used but benefit is still evident.
John George (Jun 01 2018 at 12:47):
@Grahame Grieve and @Adrian Lanzafame thanks for your replies. Perhaps then I have been misled, as I've read that Blockchain being a distributed ledger technology, DLT could reduce data fragmentation and enhance traceability and accountability with the potential for cost-savings and efficiencies of scale. My interpretation of your comments is that if as in England you have a trusted IT infrastructure for health and social care (N3/Spine) information exchange, then there are limited benefits in adapting Blockchain for the National Health Service in England. Perhaps a DLT like Blockchain would assist collaborative projects between public and private sectors in the UK, for example by increasing the integration of public and private sectors in the provision of data-driven services for patients. Well, that's just a thought, I welcome your comments, and if you have any further suggestions for any articles to read on this subject, I would be happy to hear any advice.
Grahame Grieve (Jun 01 2018 at 20:01):
Blockchain being a distributed ledger technology, DLT could reduce data fragmentation and enhance traceability and accountability with the potential for cost-savings and efficiencies of scale
Grahame Grieve (Jun 01 2018 at 20:03):
sure I've read that too. But as far as I can tell, the basic premise behind this is : we don't trust the administrators and we think that transparency will introduce an accountability that will force things to be done better. I actually follow the logic of this in some contexts (land records..)
Grahame Grieve (Jun 01 2018 at 20:03):
but my basic premise is: blockchain is the worst way to solve any problem, but sometimes trust issues leave you with it as the only way to solve a probem
Adrian Lanzafame (Jun 02 2018 at 00:32):
@John George If you want an example of an architecture that works really well interfacing between public and private sectors, I suggest having a look at Estonia's X-Road project: https://e-estonia.com/solutions/interoperability-services/x-road/
John George (Jun 02 2018 at 07:53):
Thanks @Grahame Grieve you've given me some food for thought around transparency leading to accountability, and blockchain being the worst solution but might be the "only one in town". :grin:
John George (Jun 02 2018 at 07:54):
@Adrian Lanzafame thanks for the link to the Estonia's X-Road project, I'll have a looked at this. Much appreciated.
John Moehrke (Jun 02 2018 at 16:15):
I think the problems we are seeing in Healthcare _today_ are that data are NOT moving when they should be moving (authorized use). Thus to put more technical barrier (blockchain) in the way of data movement seems counter to success. Blockchain is a fantastic tool for DLT, this simply is not the problem we have... Thus the data movement must first be solved, something FHIR is very focused on. Once we get authorized communication of this data in highly accessible and structured form, we will then want independent pathway for proof of data transfer. Even here, use of more mundane solutions like FHIR Provenance and AuditEvent fill most need. This is not to say there are no use-cases in the broader domain of healthcare for blockchain, just that treatment is not a fertile ground for blockchain. Supply-chain, payment, provider-credentialing, app-credentialing, etc. These other things are less data-sensitivity (patient data is very sensitive), and have higher value per use.
John George (Jun 04 2018 at 09:00):
@John Moehrke that's the first time, I've heard that Blockchain could be a technical barrier to data movement. However, I understand what you mean by the data movement needing to be solved first, and appreciate your thoughts on data-sensitivity. I haven't used FHIR Provenance and AuditEvent in the FHIR messaging work I am involved with in the NHS, thanks for highlighting these, I will take a look at these. I'm guessing the appropriate starting points are:
https://www.hl7.org/fhir/auditevent.html
https://www.hl7.org/fhir/provenance.html
Grahame Grieve (Jun 04 2018 at 09:43):
yes
Doug Bulleit (Jun 07 2018 at 03:02):
I've been away from this forum for a couple months and am just now catching up. But, as I've maintained previously, IMO there is a compelling DLT role that's, at least, tangential to FHIR (and vice-versa). It's based upon the concept of a self-sovereign identity enhancement built upon a decentralized OAuth2/HEART architecture. And its use cases range from materially improved security, to a paradigm shift of sorts in how Informed Consents are managed and provenance/consumption proven; from there, patients could become more engaged as active players, irrefutably granting authorizing applications access to FHIR Resources. We'll be forthcoming with more details on significant Pilot demonstration soon.
Steve Melville (Jun 07 2018 at 11:33):
I heartily agree, Doug. In my view, the paradigm shift you refer to is to truly enabling a patient-centric ecosystem. As you note, self-sovereign identity is at the core. Before I can own my own data, I need to own my own identity. But from that starting point, an entirely different architecture can emerge.
Today, information about my health-care events and conditions is fragmented across a broad spectrum of health-care providers -- clinics, hospitals, pharmacies, medical labs, etc. This negatively affects health outcomes, because each is operating from a different fragment. Assembling a holistic view of my health situation from these bits is fraught with challenges. There's the hated 10-page intake form, where I am expected to layout (again and again and again for each new provider) my complete medical history from memory. And, in order for different providers to correlate information about me, they need to associate these various bits of health-care info with my Personally Identifying Information (PII). This linkage between my PII and the health bits makes the combination Protected Health Information (PHI) from a HIPAA perspective and Personal Data (PD) from a GDPR perspective. Thus, this coupling of health data + PII, subjects them to significant regulatory constraints and liability risk. The barriers to assembling a holistic view impairs health outcomes. And the whole process leaves me (as patient, the supposed beneficiary of this whole medical apparatus) feeling vulnerable and marginalized. Pretty much bad all the way around!
What DLT (Distributed Ledger Technologies -- encompassing, but not limited to, blockchain implementations) + self-sovereign identity begins to enable is to turn this whole story on its head. Instead of providers owning (fragments of) my data, I do. I own (and store in my own encrypted private health journal) my complete story (all the bits) -- diagnostic reports, prescription histories (both the prescribing-side AND the filling-side), personal health notes, clinical & lab results, etc. Informed Consent can be expressed in non-forgeable, non-repudiable, and immutable agreements between me and a provider (stored on a distributed ledger). And I can share this info with them using pairwise, cryptographic pseudonyms (no PII unless they absolutely need it -- and the number of cases where it is absolutely needed is surprisingly small). Diagnostic report from a lab? Use the pseudonym tied to the specimen(s) on which the report was based to pop the report right back into my personal health journal -- accessible to my doctor under an Informed Consent agreement in which their access to the report is authorized and audited. Neither the Lab nor the Doctor in this scenario ever are in possession of PHI or PD -- no HIPAA or GDPR compliance issues! (It's not quite that simple... I'm glossing over many details, but the potential is there).
I'd say FHIR is central (not tangential) to this story in providing the terminology (through code systems, value sets and naming systems) and the concepts (resources) and relationships (references) that enable shared meaning in this de-centralized ecosystem.
Welcome back, Doug! I'm excited to learn more about your pilot! And thanks for mentioning HEART (Health Relationship Trust). I wasn't aware of that effort previously. I've only skimmed it, but what I've seen so far is very encouraging.
Grahame Grieve (Jun 07 2018 at 11:53):
I'm afraid that bits of this sound very out of touch with the present reality that is healthcare. Have you heard of 3 point identity check?
Doug Bulleit (Jun 07 2018 at 13:42):
Fair enough: IFO am continuously amazed at how "out of touch" the DLT community is with FHIR (and, dare I say, vice-versa). FWIW, the FHIRBlocks Project centers upon the notion of Certified Self-sovereign Identities (CSIDs) built in two dimensions: multi-factor media-driven instant user authentication (SMS, biometrics, etc,) as well as the attestable "Claims" that can bolster confidence in the user's true (and relevant: read alternative user-managed persona...but, that's another topic). Think of a CSID as a unique patient identifier that also functions as a sort of client-side digital certificate (attestable by Claims comprising FHIR Patient Resources). Anyway, pleading ignorance myself, I wasn't aware of any particular "3-point identity check." Grahame, can you point me in a direction to read more about it?
Grahame Grieve (Jun 07 2018 at 19:56):
interesting. it seems like not much of a US thing formally. It's standard practice in Au - whenever dealing with the patient, you must do a 3 point identity check to ensure that the record you are dealing with is the correct record for the patient. That is, you must compare 3 identifying pieces of information from (MR, family name, dob, national identifier, first name) every time you cross match the patient to the record. And people still get it wrong and mis-match records.
Grahame Grieve (Jun 07 2018 at 19:57):
this extremely manual process that is critical for quality rests on real world PHI. There's no crypto substitute for this in the real world - that's just a fantasy
Grahame Grieve (Jun 07 2018 at 19:57):
and each record keeper is liable for getting it right themselves; there's no delegation of responsibility on this, and you have to get it right when the patient is not present either
Grahame Grieve (Jun 07 2018 at 19:58):
here's the sole US reference I found: https://www.clinicalradiologyonline.net/article/S0009-9260(14)00260-8/abstract
Doug Bulleit (Jun 09 2018 at 23:04):
Why wouldn't a combination of biometrics (e.g.,, thumbprint, photo, etc) bound to digital badge (and/or physical bracelet for admitted patients), linked to various attestations in a self-sovereign ID file, be equal to or better (than a "3-point check)?
Grahame Grieve (Jun 09 2018 at 23:06):
in general because:
- it's a human problem; the human has to understand the match
- the patient needs to be present (and possibly conscious) for some of your options
Grahame Grieve (Jun 09 2018 at 23:08):
once upon a time, I heard a possibly apocryphal story though the source was good: 2 gay men met at a party, and discovered they had the same first and last name and birth date. Then they moved in together. Now they become indistinguishable for any 3 point check
Grahame Grieve (Jun 09 2018 at 23:09):
it's possible that there's a solution to the problem, but there's a lot of workflows and liabilities to resolve before it's actually a solution.
Grahame Grieve (Jun 09 2018 at 23:09):
however my general notion is: the weak point in all mathematically proven systems is the humans.
Doug Bulleit (Jun 09 2018 at 23:45):
The idea behind a digital "badge" is that its QR code could be scanned (or NFC'ed) at the point of care allowing a properly credentialed provider to access as many identity claims as necessary: claims that could be further attested to by both FHIR Patient Resources as well as physical markers (photo, thumb scan, etc). You're right, I suppose, the attending provider could still screw up; but even that would be hashed into the permissioned FHiRblockchain
Doug Bulleit (Jun 09 2018 at 23:50):
I'm not sure how unknown and unconscious folks are ID'ed (under any system); but, in the case of an admitted patient, they would have bracelet with either NFC chip or a simple QR code. And, the remote patient would simply use the digital wallet/badge itself for authentication
Grahame Grieve (Jun 09 2018 at 23:53):
unknown patients are treated as a John Doe if there's no relatives / friends to identify them. In one case, back when I was working in a hospital a long time ago, a young man was hit by a car and admitted as a a John Doe. It was 2 weeks before he passed away, still as an unclaimed John Doe. Eventually someone from an embassy turned up to claim the body....
Grahame Grieve (Jun 09 2018 at 23:54):
as for remote patient - not quite the point. There's a lot of care processes that happen behind the scenes with no patient involved - typically, on bits of the patient after they have been removed ('specimens' - identity chain must be safe on them)
Doug Bulleit (Jun 10 2018 at 00:58):
At least in the FHIRBlocks world, and apart from occasional Resource Get's from the FHIR Server (and even more restricted eventual write transactions), the EHR (and other App's) itself is unaffected; thus, everything happening "behind the scenes", and in ordinary Provider Workflow, is business as usual e.g., current patient identifiers, MRNs, etc, remain in place. Indeed, by binding itself to these parochial identifiers, FHIRBlocks CSIDs (certified self-sovereign IDs) could comprise a sort of user-managed (inter-IDN) UPI
John Moehrke (Jun 11 2018 at 12:45):
There is a large gap between where we are today, and that consensus-identity-authority you describe. The gap is not technology, many technologies have filled the gap, and failed. The gap has political aspect, in the USA there is forbiddance. However that doesn't prevent various identity schemes from being created. The biggest problem, which is related to Grahame's point "... each record keeper is liable for getting it right themselves;...". There needs to be a political action to allow this identity proofing to be outsourced, with that comes outsourcing of liability if the identity is wrong, which covers all damages of being wrong. I don't see how any self-sovereign identity scheme does this, regardless of how fancy the technology is -- Certified Self-sovereign Identities (CSIDs). The problem is not technical, it is legal and ultimately very expensive.
John George (Jun 12 2018 at 09:11):
Hi @John Moehrke you mentioned "forbiddance", something that I am not familiar with. After searching the term I came across this, that happens to be your blog :grinning: :
<https://healthcaresecprivacy.blogspot.com/2016/04/patient-id-is-critical-to-enabling.html>.
It mentions that "in the USA we are up against a forbiddance of USA Government funding of a national patient ID". Why is the USA Government against funding a national patient ID? Or bearing in mind that blog was written 2 years ago, perhaps they have they changed their position?
Grahame Grieve (Jun 12 2018 at 09:41):
.. politics ;-)
John George (Jun 12 2018 at 10:04):
Surely they don't think a national patient id would lead to pressure for a USA national health service! :wink:
John Moehrke (Jun 12 2018 at 12:03):
The position against any federal funding of an establishment of a national patient ID goes back to 1996 and HIPAA. I was not yet involved in healthcare at that time. I understand it was intended to be a Privacy thing, by not having a federally managed patient identifier the government would never know who you were... Of course the opposite is actually true because we now must share very high quality demographics at almost every communication. Note there is not forbiddance to have a patient identifier that spans the nation, just that the creation of this identifier can't be funded by the federal government. The problem is no one wants to do that, because it costs money.... There are nationwide initiatives that have identifier federation, thus having one identity without one identifier. So what was to help privacy, has done the opposite...
John George (Jun 12 2018 at 13:22):
@John Moehrke thanks for the background to the national patient ID, 1996 is a long time ago, I was an undergraduate studying Biochemistry back then. That's interesting because as you suggest, by sharing high quality demographics, you could indirectly track the patient, circumventing the USA Government's forbiddance to use the national patient ID.
Doug Bulleit (Jun 12 2018 at 13:53):
Thanks John for that explanation (and to the group at large for engaging on this topic); IMO we may have, at last, found traction on where DLT (permissioned blockchain tech) fits into FHIR (or not). IMO, much of the answer to the oft-asked Why blockchain question is non-technical. Indeed, on the instant UPI issue, the concept that I'd like to get your opinion on may be likened to a 'through the looking glass' situation: i.e., one where many ot previous assumptions are reversed. For example, setting aside the perennial Who owns the data question, if/when we can prove that a given patient irrefutably controls access to her own PHI, won't a lot of the political (e.g., HIPPA) proscriptions fade? And, to lesser extent, can't some of the problems with identity be addressed by an end-user bringing a high-trust identity of their own to the encounter?
Grahame Grieve (Jun 12 2018 at 13:55):
doesn't the user bring their own existing high trust identity to the table: "I am me and I know that". Everyone else's problem is not identifying me, but matching me to my record
John Moehrke (Jun 12 2018 at 14:08):
as Grahame has said... There are plenty of identities, adding yet another will not help unless organizations can have protection from liability because the identity is backed by regulation (aka a federally manged identity). Bringing technology to political fight -- much like bringing a pretty knife to a gun fight... AND in the case of blockchain, the technology is unapproachable except by the most elite tech-people. So it is even an inappropriate type of pretty knife.
Doug Bulleit (Jun 12 2018 at 15:08):
Well, as the old work farm warden said to Cool Hand Luke, "What we have here is a failure to communicate." And, I'll take the blame for that. Mixing metaphor, the "pretty knife" can both cut off and cut through complexity (for both patients and providers alike). Sure, we all know who we are, but passports and drivers licenses help us prove it. And while holders of them may not care what and how the numbers and QR codes on them do, the various data repositories and (digital) "Claims" that they can invoke matter to anyone that needs to know your various credentials to proceed with the admission or service to be rendered. Similarly, a digital "Health Badge" can bind itself to any number of Claims (including FHIR identifiers, MPI,s, MRNs etc). Moreover, the multi-sig smart contract feature of blackchained-enabled CSIDs, permits IDNs to federate their respective users' IDs. Anyway, just as you don't have to understand how a smart phone can pay for a cup of coffee or to board an airplane, none of this "complexity" needs to be understood or assimilated by anyone other than the "elites" that design the platform.
John George (Jun 12 2018 at 16:01):
Hi @Doug Bulleit I wasn't sure if you were thanking @John Moehrke or me? :wink: I'm trying to understand if Blockchain is a Technology looking to find a solution, or an implementable solution that could be a future game changer in health informatics. There is certainly a lot of hype surrounding Blockchain and I am thankful to all that have contributed to this discussion as I have found this very educational. I am aware of a pilot project at a single NHS hospital in England to use Blockchain to check the professional credentials of Doctors against the various databases of the various Royal Colleges, for example to check that a Surgeon has a Fellowship from the Royal College of Surgeons, as there was a problem with a minority of Doctors falsifying their qualifications. Yet this is just one project, it may take off, and if it's a success it may get rolled out nationally, or it may not be a successful, or maybe too costly to implement, etc... Regarding, @John Moehrke comment about Blockchain being a technology that "is unapproachable except by the most elite tech-people", I see parallels with HL7v3, as I recall around 13 years ago some IT suppliers in the UK saying the same thing about HL7v3!
Doug Bulleit (Jun 12 2018 at 16:11):
George. Thanks for your comments and questions. The proof of blockchain relevance will be in the pudding of certain impending Pilots: e.g., Humana, Optum/UHC , MutiPlan and Quest Diagnostics just announced a large-scale permissioned-blockchain pilot that they'll be launching this summer; similarly, we'll be forthcoming with details on a FHIRBlocks pilot being planned with several large IDNs to be implemented in the fall; and I'm sure that there are any number of others in the works. So, sooner than some may suspect, blockchain relevance to FHIR (and vice-versa) will no longer be so much a subjective debate as a topic for serious consideration
Steve Melville (Jun 13 2018 at 10:34):
"I'm afraid that bits of this sound very out of touch with the present reality that is healthcare."
Actually, it is precisely my keen concern for the "present reality that is healthcare" that provides the motivation for conceiving of a potentially better future reality of healthcare. I acknowledge, however, there are significant barriers to altering the present reality in any significant way. And, my apologies for waxing enthusiastically about the potential future reality without giving voice to the forces working against such change. As other comments on this thread have noted, there is a very large body of current practice that is built around existing notions of human identity and existing human processes for verifying identity. And, for all of its flaws, this body of practice holds the very real advantage of having been forged from the crucible of real world experience of healthcare delivery. So, it is unwise and even irresponsible to suggest that all of that accumulated wisdom be cast aside in favor of some new wunder-technology.
Add to that the astonishing degree of hype around blockchain, and it is quite understandable (and warranted) to treat any DLT proposals for healthcare (or any pure technology proposal, for that matter) with a healthy degree of skepticism.
Still, I remain hopeful that a useful common ground can emerge from this discussion. In reviewing this thread, I tend to agree with @Doug Bulleit about there being a failure to communicate. Not only are their lots of (unexpanded) acronyms being thrown around, I'm guessing there is a pretty broad disparity in the understanding of Distributed Ledger Technologies (DLT), attestations, and Certified Self-Sovereign Identities (CSID). Furthermore, I sense part of the miscommunication may lie in differing understanding about what problem(s) we are actually trying to solve.
In situations like this, I've found focusing on specific concrete examples to be very helpful in cutting through the misunderstandings. In the interest of helping us all navigate these deep, broad and muddy waters, I'll humbly offer a couple of concrete examples in a subsequent post.
Steve Melville (Jun 13 2018 at 10:57):
Example #1) A nurse is about to administer medication ordered by a physician to a hospitalized patient.
There are (at least) four relevant actors: The human patient, the hospital that admitted the patient, the physician who has assessed the condition of the patient (with the help of a medical record (MR) for the patient) and ordered the medication, and the nurse who is about to administer the medication to the patient. Can we agree that what is important here is ensuring that each actor's view of "the patient" refers to the same human being?
The 3-point check approach uses some facts about the patient to tie all the views together: (<family name>, <given name>, <dob>, <national identifier>). An advantage of (at least the first three) is that the patient (if conscious and lucid) can verify them verbally to the nurse administering the medication for comparison to those same facts on the MR. They could also be included on a bracelet attached to the patient by the hospital at time of admission.
Clearly, there are a number of potential failure points: (a) typos at the point of data entry to the MR could result in incorrect facts being recorded in the MR (e.g., transposing digits in birthdate, typos in names), (b) the physician could confuse two similar MR's and incorrectly order the medication for the wrong patient (c) the nurse could forget to perform the 3-point check, (d) under repetition-fatigue, the nurse could automatically "hear" an affirmative response or the patient could automatically give an affirmative response without really listening to the response or question, (e) the patient could be incapable of responding coherently to the verification questions, (f) two patient's may share the same 3-point facts (Grahame's apocryphal story).
Given this problem statement, it's worth re-asking Doug's question:
Why wouldn't a combination of biometrics (e.g.,, thumbprint, photo, etc) bound to digital badge (and/or physical bracelet for admitted patients), linked to various attestations in a self-sovereign ID file, be equal to (or better than) a "3-point check"?
Doug... would you be willing to walk us through this example, and specifically explain the role that CSID's, attestations, and DLT could play in this scenario? And how they may mitigate one or more of the failure points?
It would be helpful if you also addressed the concerns expressed by @John Moehrke and @Grahame Grieve about legal liability. I don't believe the solution you are proposing depends upon outsourcing liability away from each record keeper's obligation for "getting it right themselves." Rather, I think you are proposing reducing their liability by providing more reliable "facts" on which to get it right. But, I'd like your take on that.
Lloyd McKenzie (Jun 13 2018 at 12:07):
1. Biometrics have points of failure too - especially in a healthcare setting where there's a higher likelihood that whatever biometric was chosen has been exposed to trama, is covered in blood, is hard to get at, etc.
2. Biometrics mean that every point of contact where a 3-point check needs to be performed now would need to have the technology available to do a biometric scan and that technology would have to be pretty-much fail-proof. If electronic systems go down, you can do a 3-point check against a paper chart. But it's pretty much impossible to check a finger print or iris scan if the database is inaccessible.
3. The level of trust required to get patients to share their fingerprints or other biometrics is significantly higher than getting them to share their names and date-of-birth. That's not necessarily logical, but it's reality
4. Even if we made the switch, it's not at all clear why block chain is necessary for the solution.
Grahame Grieve (Jun 13 2018 at 13:05):
also, you have to match the patient to the record in the absence of being able to do biometrics. e.g. you have a bit of them. Or they're unconscious....
Doug Bulleit (Jun 13 2018 at 14:10):
I'm on the road for a couple of days; but, as soon as I get settled I respond more completely. But my first reaction would be a semi-glib allusion to the old joke about how fast one has to run to escape the hungry lion? (only a bit faster than the next guy;-). IOW, nothing's perfect; but, in a gathering crowd's view, a self-sovereign identity (which by its nature suggests a blockchain adjunct) materially improves both trust and the functionality (as well as the speed;-) of conventional authentication and authorization as well as on-the-spot identification.
Lloyd McKenzie (Jun 13 2018 at 14:30):
The thing is, we don't generally have a "trust" issue. Patients are happy to share far more sensitive information than their identities in a healthcare setting. It's not clear how blockchain is more useful than centralized databases in this space. Given the increased cost and complexity of the proposed solution, it's got to be significantly better than the current solution to have a hope of getting off the ground, and I'm having a great deal of trouble seeing even a small advantage.
Steve Melville (Jun 13 2018 at 20:52):
While we're waiting for Doug's travels to land him in a stable location long enough for him to respond, I'll offer a couple of simple explanations of self-sovereign identity (SSI). I'd encourage you to read them even (or perhaps, especially) if you think there couldn't possibly be anything about self-sovereign identity that could change your fundamental position. That way, we all can have a shared base-level of understanding about what SSI is and what problems it is (and isn't!) trying to solve.
1. How Blockchain Makes Self-Sovereign Identities Possible
As its name implies, this paper demonstrates the role a public blockchain may play in facilitating self-sovereign identities. As an aside, I'll mention that blockchain is the best known DLT, but there are a wide range of blockchain implementations that exhibit very different characteristics. There are also non-blockchain-based approaches to DLT. (Personally, I believe holochain is, for most use cases, vastly superior on a whole number of fronts to any of the blockchain implementations, but that's a topic for another time).
2. A gentle introduction to self-sovereign identity
This paper offers a good easy-to-understand explanation of self-sovereign identities, though it is a bit biased towards financial services applications (it is written by someone who works for R3, the providers of a private, permissioned blockchain product purpose-built for the financial services industry).
For those wanting to go deeper, I'd suggest the Decentralized Identity Foundation's DIF site. DIF is a consortium of a number of companies (including IBM, Microsoft, Mastercard, Accenture, and most of the SSI-software companies) that are working with W3C to develop standards for decentralized identity.
One final note... I offer these readings to promote more precise and effective communication on this thread, not to suggest that self-sovereign identities are the magic answer. They are just one component of a larger solution that it appears FHIRBlocks is working on (I'm not affiliated with FHIRBlocks in any way and I can't and don't want to speak for Doug). I respectfully suggest that folks refrain from posts along the lines of "self-sovereign identities can't work in healthcare because they don't do X or handle Y" until Doug has had a chance to chime in with how he sees FHIRBlocks concretely addressing the example I offered in an earlier post.
I really appreciate the level of engagement on this thread and the accumulated wisdom people are bringing to the table. To me, a knowledgeable, skeptical community is the ideal proving ground for vetting new ideas. And I applaud Doug's courage and equanimity in bringing his ideas to this forum.
Doug Bulleit (Jun 13 2018 at 23:22):
Wow! Thanks a million Steve; while I really appreciate the challenging questions I sometimes find on this board, I hadn't expected to find a friend here;-)
Anyway, I'm not exactly sure where to start; so, I'll just pick up with where you (and Lloyd) left off.
A quick scan of the links that you've already provided look good; and for anyone wanting to read more about it, I'd recommend a deeper dive into Sovrin/Indy (and/or, for the public blockchain-inclined, uPort). The easiest way to think about SSI (or CSID in FHIRBlocks parlance) is through a physical ID metaphor: just as a visit to your Doctors; office often entails a request to see your Drivers License (for basic attestable identity "Claims") and your insurance card (for corollary Claims of insurance coverage) and, occasionally even back ground credit check, an SSI goes one step further--i.e., it places a digitally-signed version of these these and other Claims in your wallet (or digital health badge). The idea here is that the combination of these signed & attestable claims are not only more powerful than the sum of their parts, they're now under the complete control of the individual (versus some centralized IDP).
Moving on, while a blockchain is not absolutely necessary to SSI, there are several compelling, largely non-technical, reasons to go that way: e.g., a decentralized ledger eliminates the "honeypot" (thus destroying many a hackers business case); it provides a convenient place to deposit ZKP hashes made over authenticated/authorized SII transactions; and it creates a truly P2P ecosystem wherein no DLT participant's agenda is in any way subordinated to another's (let alone an IT vendor's)
Now, returning to your scenario: I may have carelessly veered off FHIRBlocks' current roadmap--i.e., we are working on a stronger and more versatile approach to a remote authentication/and inter-EHR-interoperability appoach (via decentralizing OAuth2/OIDC/HEART functions within smart DLT contracts). The notion of triggering an SSI-driven identity check via a QR code and/or URI printed on a physical card, was something of afterthought. IOW, a SSI or CSID isn't about displacing on-the-spot patient-provided info; rather, it's about a quick and easy way to verify and "prove" it. Thus, as you say, it doesn't remove a provider's responsibilities; but it could make the job easier. It's initial target use case target is merely to replace wet signatures with a superior alternative (thus relieving certain Consent Mgmt workflow) and, down the road, allowing patients to self-authorize mHealth application access to FHIR Resources
One last comment on the "C" in CSID...
A practical early problem with SSI involves the time and trouble of getting a critical mass of validating authorities into the system. We believe that the robust nature of "Claims" latent within a typical EMR may point to short cut. Indeed, an EHR-certified ID may could become a Sovrin* et.al cornerstone! IOW, FHIR-based Patient (and perhpas other) Resources may unilaterally comprise a solid SSI in and of themselves.
'hope this helps (and that the dialog goes on)
- As you may have surmised, FHIRBlocks is being built upon a permissioned blockchain (thus Sovrin/Indy); the rationale for that may (subject to audience interest;-) be the target another entry
Lloyd McKenzie (Jun 13 2018 at 23:34):
The identification information can't be in the complete control of the individual. Once you share insurance number, name, phone number, etc., they're going to be recorded and it's going to be used by the hospital based on their business processes. And the patient has little say about that. Furthermore, the healthcare delivery organizations feel they have a need for that information. They can't function if the patient somehow revokes their access to the insurance information that would allow them to be paid. Furthermore, it's not clear that more than a small minority of patients care about sharing this information. We are, after all, talking about consumers who regularly expose sensitive information on Facebook, Google and other platforms that have no need for it and don't make life & death decisions on behalf of the patient.
It may well technically work, but it's not clear what the "pressing business need" is that would justify the cost of the change.
As an aside, with a 3-point id, identification can be made by a third party (mom bringing in their infant, husband bringing in unconscious spouse). It's not clear how this would work in a situation where the identify information is in full control of the patient.
Doug Bulleit (Jun 13 2018 at 23:47):
Well, we could go on here; but, again, think of it as merely the equivalent of the ID's that you carry in your physical wallet. Each time you show up at a provider location they need to see (and sometimes check) the Claims represented in them for current status. The IDN's that we're working with indicate that the workflow reduction that may attend this ritual as well as replacing wet signatures on 10 page Consent forms alone could save enough to "upgrade" from current UID/PW and manual methods.
Grahame Grieve (Jun 13 2018 at 23:47):
I think there's different problems being discussed and addressed here. There's the problems that healthcare shares with other industries, about consistent distributed identity. But there's something different about healthcare (though it's not unique to healthcare): liability for identification and choosing the correct is not delegated. (other obvious context where this matters: legal system)
Grahame Grieve (Jun 13 2018 at 23:48):
what we're saying is that the lack of delegation of liability complicates all the workflows and is something that any proposal to change things has to account for.
Doug Bulleit (Jun 13 2018 at 23:57):
Good point! And, resolving that question is at the dead center of the current Pilot implementation that we're building. Do have any guidance on how to more fully define the issue? Again, we're not really so much interested in displacing the in-person (physical card) situation as we are in building irrefutable CSIDs to remote mHealth app's
Grahame Grieve (Jun 14 2018 at 00:02):
I'm not sure about good guidance. The 2 things I think people need:
- clear documentation about how the id changes their record matching process in a way that still meets their liability obligations
- case law showing that it's valid (that's frightfully expensive, but that's the wold you live in here).
Steve Melville (Jun 14 2018 at 00:28):
I'm going to once again suggest we get much more concrete. As Grahame stated, there are different problems being discussed here and I personally would benefit from clearer problem definition. The issue of liability keeps coming up and while I have a general sense of what that means, it would be great if someone could frame exactly where the liability question(s) arise within the context of the example I provided (or, alternatively, do so with their own example).
Doing so may allow us to move towards possible collaborative solution design (or to collectively reach a conclusion that no feasible solution exists).
Doug Bulleit (Jun 14 2018 at 00:43):
Steve. I agree; and, I'm getting some input on the questions here from several CSO and CIO's from leading US IDN's. Sadly, even they are at a bit of a loss to nail down success criteria on the kernel of our MVP (or minimum viable product): i.e., replacing "wet signatures" with legally-binding digital equivalents. But in an attempt to be as clear as possible about our MVP, our initial use case involves a interfacing a registered CSID to the IDN's document management system thus facilitating various Informed Consent acquisitions and proofs
Grahame Grieve (Jun 14 2018 at 00:46):
this might help make your problem more concrete
Grahame Grieve (Jun 14 2018 at 00:48):
- https://www.theguardian.com/australia-news/2018/feb/05/man-died-from-medication-mix-up-following-day-surgery-coroner-hears
- https://www.smh.com.au/national/nsw/paul-lau-died-at-sydney-hospital-after-wrongly-being-prescribed-fentanyl-inquest-20180205-h0twtn.html
Grahame Grieve (Jun 14 2018 at 00:48):
this is clearly human erorr, but the coroner's recommendations make for sobering reading
Grahame Grieve (Jun 14 2018 at 00:50):
https://aushealthit.blogspot.com/2018/04/the-coroners-recommendations-on-death.html
Grahame Grieve (Jun 14 2018 at 00:51):
particulalry recommedation #2.d -
Doug Bulleit (Jun 14 2018 at 12:17):
Sigh...'more then before I regret this thread's veering off into in situ clinical care scenarios, as FHIRBlocks' primary use cases involve on-line scenarios. That said, I still don't see how/why an NFC or GR coded bracelet triggering a CSID transaction wouldn't be useful in insuring that the correct PII (if not PHI) is brought forward at the point of care; and, to your legal/risk/compliance points that its use (of not use) becomes immutably recorded to a ledger. That doesn'tt fully obviate the possibility of human error but, 'seems to me could help.
As to Lloyd's comment, the assumption here is that the EHR already has all the information (e.g., FHIR Resources). All the CSID does is give the Patient the ability to share access to it to selected applications (and, by Consent, to clinical staff)
For more color on these concepts, you may want take a look at Adrain Gropper's work at patientprivacyrights.org. Also, here's a pretty good paper on self sovereign identity IdM-on-Blockchain.pdf
Steve Melville (Jun 14 2018 at 12:35):
Thank you, Grahame, for providing this illuminating, if tragic, example. One of the things this example illustrates is that the real-world is messy and complicated. As the report notes, there were 15+ different points at which a life-saving intervention was possible. (I wish the report had enumerated those! Considering each of those points would probably yield a number of insights). Clearly, the primary precipitating cause was the anaesthetist's confusion regarding whose MR they were entering the medication order into. This corresponds to failure point (b) in my Example #1. This is a particularly insidious failure point because no amount of downstream identity verification would catch this problem. Once the order intended for Patient X was (incorrectly) placed in Patient Y's MR, the nurse performing either the 3-point check OR CSID verification, would only confirm that it was indeed Patient Y receiving the medication. In this case, the place where the identity verification would have helped would have been in the anaesthetist's interaction with the EMR. The coroner's recommendation #2.d to have the anaesthetist (re-)enter the patient's name (essentially a "1-point" check) is one of many possible user experience enhancements that could help prevent this type of error.
It is worth pointing out, however, that the coroner's recommendation in this one case is not the same as a legal-mandate to perform a particular identity verification method (e.g., 3-point check). Seems like more of a system's design issue (which means the door is not slammed shut on innovative design approaches).
Steve Melville (Jun 14 2018 at 12:42):
Well.. the good news, Doug is that by pressing for a concrete example we've learned something important! ;) Namely, that your sweet spot lies with a different set of use cases than in situ clinical care scenarios.
How about shifting gears to your primary use cases? Can you lay out a concrete example that is representative of the kinds of problem(s) your are focused on solving?
Doug Bulleit (Jun 14 2018 at 15:16):
Yes thanks! I'm not sure how much more detail would be useful here. Previoulsy I described it this way...
"...the kernel of our MVP (or minimalist* minimum viable product) involves replacing "wet signatures" with legally-binding digital equivalents. And in an attempt to be as clear as possible about our MVP, our initial use case involves interfacing a registered CSID to the IDN's document management system thus facilitating various Informed Consent acquisitions (two-sided digital signatures) and (hashed ZKP) proofs."
I could append a web sequence diagram if you like. But that could take us down a different alley--i.e., the purpose of the initial MVP Pilot is merely to prove the feasibility and usability of a CSID; thus a simple Consent Mgmt UiX/App. The challenge back may be that there are less complex ways to accomplish that use case. But again, the idea is that , by decentralizing and inverting the OAuth model, a CSID could animate a wide range of other app's. But we have to start somewhere...
John Moehrke (Jun 14 2018 at 18:39):
Note the liability issue is not just with death, pain and suffering is just as important, if not more important. Where in the banking industry there is only money loss, healthcare is far more personal loss. Money loss can be refunded, personal pain loss can't
Doug Bulleit (Jun 15 2018 at 14:38):
Noted: all the more reason to consider more powerful ID/Resource access tools.
Also John, thanks for posting the following article on LinkedIn...
https://www.linkedin.com/pulse/authorization-through-fhir-consent-jaime-olivares/
Steve Melville (Jun 16 2018 at 20:29):
Hi Doug. Here's what I would suggest... imagine a real-world scenario that typifies your ideal case. You can substitute fictional names for actual people/companies, but other than that it should read like a case study. I assume by IDN you mean Integrated Delivery Network... i.e., "a formal system of providers and sites of care that provides both health care services and a health insurance plan to patients in a defined geographic area". So pick a small number of actors in such a network (including the patient) and provide a short narrative. Something along the lines of the following:
1. Person X creates a CSID (perhaps provide a high-level summary of what that entails, since I'm guessing many, if not most, on this thread are not familiar with that process and the two-dimensional aspect of CSID's seems an important part of your "secret sauce").
2. Person X experiences some worrisome symptoms and visits clinic C to be examined.
3. At the clinic, Person X provides their CSID (or a pairwise pseudonymous identifier tied to their CSID) along with some other 3-point check type of identifying information (if you think this is appropriate in your scenario) to Clinic C.
4. Doctor D logs in to the clinic's health care system and uses X's identifier to access their EMR.
5. Doctor D reviews the EMR, examines Person X and decides lab work is needed to diagnose X's condition.
6. Doctor D enters records their Observations in X's EMR and enters a ProcedureRequest for Lab L to draw and analyze Person X's blood.
7. X visits Lab L to have their blood drawn and initiate the analysis. How does Lab L know who they are? How is their identity correlated with the ProcedureRequest?
8. Lab L draws the blood (creating a Specimen that needs to be verifiably associated with X), analyzes the Specimen, adds a DiagnosticReport based on that Specimen to patient X's EMR with the DiagnosticReport.
9. Doctor D reviews the DiagnosticReport for Person X received from Lab L...
... and so forth
This narrative gives you a backbone on which to relate how X is identified in each of these interactions and how X's identity is known and verified to the clinic, the doctor, the lab, and tied to their EMR, the ProcedureRequest, the Specimen gathered by Lab L, the DiagnosticReport created by the Lab from the Specimen, etc.
I've seen these kinds of concrete scenarios be much more effective at teasing out specific issues (and, hopefully, solutions!) than bandying concepts back and forth.
Just a suggestion... :simple_smile:
Lloyd McKenzie (Jun 16 2018 at 21:47):
The other thing that would be useful is to explain what the process would look like without blockchain involved and what problems in the scenario the existence of the blockchain would resolve/avoid/mitigate.
Abbie Watson (Jun 18 2018 at 04:19):
Agreed with Graham on the legal/jurisprudence angle. The value proposition that smart contracts offer is highly dependent on whether the local government recognizes them as legally binding. So it’s going to be a state-by-state development (or nation by nation). Currently, there are only ~8 states in the US that recognize blockchain smart contracts as legal documents. Once a state greenlights blockchains, then they’re simply a distributed database that organizations can opt into. The more blockchain projects I work on, the more I’m convinced that people really overthink it.
Doug Bulleit (Jun 18 2018 at 14:47):
Steve. I tend to agree with Abigail that, at least in some respects, we may be "overthinking" blockchains' potential impact. On the other hand, it's sometimes the most subtle changes that are the most profound.
I'm jammed up today, but I'd like to take a considered swing at your thoughtful outline. But, for right now, let me just say that FHIRBlocks' mission is decidedly more modest than you may have presumed. It does not aspire to intermediate patient/EHR interchange. Rather, it merely offers a decentralized approach to authentication/authorization; various FHIR App's themselves must handle the protocols and dialogs from there. That said, IMO, the CSID "inversion"--to true user-managed access control--could, in fact, have profound effects not only upon how legal, compliance and risk management issues are managed (if not mitigated) but on how mHealth applications business models evolve.
Anyway, `more to follow...and thanks for hanging in with me so far!
Steve Melville (Jun 18 2018 at 18:50):
Hi Doug. No problem. I'm just trying to help facilitate a useful conversation here. Certainly no pressure from my side. As for the outline I provided... it was just an example of what a concrete story might look like. Feel free to use an entirely different "outline" of your own choosing. Whatever you feel best illustrates the sweet spot of what you are trying to do -- e.g., maybe just focus on the CSID identity creation experience and the authentication/authorization flows. IMHO the most important thing is that it reads like an actual scenario narrative.
Doug Bulleit (Jun 28 2018 at 15:05):
Steve. So sorry to have dropped off of this thread for a few days, as I really appreciate your "facilitating a useful conversation." My delay in picking up the baton stems from an attempt to pull in several distinguished players involved in the Pilot that we're planning. Unfortunately, a combination of summer vacations and internal announcement procedures are preventing my IDN partners' stepping forward. Hopefully we'll get past these obstacles soon and I'll be back then. Alternatively, I'll outline our work a de-identified way.
In all events, thanks so much for your continuing interest and assitance
Grahame Grieve (Jul 02 2018 at 15:13):
Doug Bulleit (Jul 04 2018 at 00:23):
Thanks for posting the Vanderbilt paper, as it has some similarities to FHIRBlocks; main differences are in core orientation (provider vs patient-centric) and public (vs permissioned) blockchain.
`more to follow...
John Moehrke (Jul 05 2018 at 16:45):
It is hard to push through the BS... but as far as I can tell the actual communication of the medical data, and the format of that medical data, is presumed to be simply FHIR (It could just as easily be eHealth Exchange (XCA)).
What they are doing is saying that all access requests will be by an identity verifiably on some blockchain. Thus everyone must be provisioned an identity in some blockchain. They skip over how this is done. They skip over to what level of assurance this is done. They simply indicate that these public identities can be verified because of public/private key basis that blockchain is built on... So, we know the identity being claimed in a data request can be verified. We don't know what that user structural-Role is, and there seems to be no recognition of a need for functional-role, or purpose-of-use... There is not even a mention of the organization from which this user is representing (hospital); which we all know users often work at many hospitals/clinics... But we can forgive students...
They then seem to imply, without any details, that the patient has a smart-contract already asserted. That this smart-contract would have identified this requesting user. Given that there are no role or purposeOfUse or identified authorized organizations, it must be an explicit reference to this requesting user. A smart-contract like this would be simple, much like a bitcoin smart-contract. So, it would be easy to verify that the smart-contract is a good contract (their mention of the high incidences of poorly written smart-contracts).
This smart-contract would thus PERMIT or DENY the request. They imply that the PERMIT might have a timeframe on it... so, some kind of token that has timeframes... like an OAuth token?
Lastly, they completely whitewash the problem that the data custodian must open their API to the authorization tokens from this blockchain system... Which is the chicken/egg problem we have today. They don't trust anyone else but themselves, so why would they trust a distributed system that has no way for them to get remediation of failures to properly act. That is to say, the blockchain system (FHIR chain), as a distributed system, has no one to take any liability for failure. Failure might be false-positive, or false-negative. This is the problem with ALL systems today. This is why all healthcare custodians control their own consent system, because it is the only way they can operate. They can't assign liability, so they must keep control.
Seems HEART can do all of this, and in a much more full-featured way... and a more robust understandable way.
Grahame Grieve (Jul 20 2018 at 23:20):
https://twitter.com/vgcerf/status/1019987651301081089 ;-)
Gustav Vella (Aug 19 2018 at 19:31):
If you jump to page 24 https://www.ecmm.info/news/forward-act-for-antifungals-new-us-initiative-finding-orphan-disease-remedies-with-antifungal-research-development/ (FORWARD BILLS-115hr6562ih) you get a vague (very vague) idea of what NIH thinks blockchain could be useful for...
Josh Mandel (Aug 20 2018 at 04:27):
It's at least what someone considered palatable as part of a broader antifungal research program. My quick assessment: if you have to trust the query engine to log all of its queries to a blockchain, then you might also be willing to trust a regular public log that the query engine maintains. (There are obviously stronger ways to architect this, but I'll wager that what eventually gets built doesn't provide any really interesting guarantees.)
Last updated: Apr 12 2022 at 19:14 UTC
