Stream: blockchain
Topic: Background
John Moehrke (Mar 16 2017 at 12:06):
Useful article from Gartner: Top 10 mistakes in enterprise blockchain projects http://www.gartner.com/smarterwithgartner/top-10-mistakes-in-enterprise-blockchain-projects/
John Moehrke (Mar 16 2017 at 12:10):
Useful technical decomposition from Kantara, who document what makes a good use of blockchain and what does not. Includes a set of use-cases with details. I participle in this workgroup. http://kantarainitiative.org/confluence/display/BSC/Home You should be able to read the Report, in google document form. It is out for public comment right now.
John Moehrke (Mar 20 2017 at 19:28):
I just added a set of criteria that a Healthcare use of Blockchain should measure up to. I don't claim this is definitive, but rather a start https://healthcaresecprivacy.blogspot.com/2017/03/healthcare-blockchain-use.html
Doug Bulleit (Mar 20 2017 at 21:17):
John
I'm at the "Healthcare Blockchain Summit." And (notwithstanding the fact that I was actually a featured speaker there this afternoon;-) the overall quality of both the presentations and the apparent sophistication of the audience here is quite impressive. As you'd imagine, I could fill pages with with interesting insights offered. That said, my headline remains the same: The mutual indifference of Blockchain and FHIR folk is breathtaking [present company, of course, excluded;-]
John Moehrke (Mar 20 2017 at 21:46):
and yet... Blockchain on FHIR.... would be so very buzzword compliant... sexy...
Doug Bulleit (Mar 20 2017 at 23:15):
Yep..go figure.
BTW, FWIW, I'm working on a White Paper on a concept that we' dubbed FHIR(R)Blocks*: one that may strike a blow in more than mere buzzword fashion
*respecting, of course, HL7's registered TM
Abbie Watson (Mar 20 2017 at 23:38):
We just added support for the FHIR Patient resource to our blockchain audit log. Next up is the AuditEvent resource.
https://github.com/chafey/ethereum-hipaa-audit-log-improved/pull/1
Grahame Grieve (Mar 20 2017 at 23:38):
so what does that mean, to support it?
Grahame Grieve (Mar 20 2017 at 23:39):
I'm imagining that block chain has a blob in which you put a Patient resource. And I"m supposing that it makes no difference to blockchain that's a FHIR Patient as opposed to anything else it could be?
Abbie Watson (Mar 20 2017 at 23:46):
Pretty much. The etherium-audit-log example was creating using a custom Patient object, and storing into a Patients collection. That Patients collection now uses the FHIR 1.6.0 schema. When the Patient object gets created, it writes items into the blockchain ledger. Next step is to put an event hook on the Patients collection, so the blockchain ledger is updated when updates come over the REST API. The demo is pretty clever. The blockchain mining is happening in the background; and you can see the ledger get hashed and updated when a Patient is created or viewed (through the user interface). Meteor on FHIR apps which use the FHIR collections can all benefit from a single blockchain mining node; and once we get the event hooks, it should be supported via REST APIs also.
Abbie Watson (Mar 20 2017 at 23:47):
Kudos to Chris Hafey and the team at Nucleus.io who did all the crypto work; I'm just updating their audit log with FHIR schema(s).
John Moehrke (Mar 21 2017 at 11:44):
I would certainly agree that AuditEvent could be the basis of a BlockChain based audit log. A selected subset (CRUD) of audit events. How is the patient privacy protected, while still using public ledger (aka block validation by miners)? Not that I expect all problems to be solved during early day...
Josh Mandel (Mar 21 2017 at 14:23):
@Abigail Watson interested to learn more; is the API (or code) for a http://nucleus.io/ audit log published somewhere? The web site doesn't include a ton of detail :-)
Abbie Watson (Mar 21 2017 at 14:39):
Here's the demo.
https://github.com/chafey/ethereum-hipaa-audit-log-improved
You'll need to follow some links, and install the etherium network to get the blockchain mining node; install MetaMask to access the ledger ; RoboMongo if you want a Mongo database manager; Postman if you want to test the FHIR API.
Abbie Watson (Mar 21 2017 at 14:43):
Right now, we're not updating the ledger when a Patient resource is created via REST endpoint; only when it's created via the user interface, which uses a websocket connection (i.e. a Subscription). There's a pull request submitted to get the event hooks in place to update the ledger via REST endpoint.
Grahame Grieve (Mar 21 2017 at 16:04):
what metadata do you need to store along with the actual blob for the patient resource? a mime type, say?
Abbie Watson (Mar 21 2017 at 16:09):
There were two fields on the original object, transactionHash and contractAddress. I was able to create an extension and attach that to the Patient object. Tentatively thinking that registering a patient-ethereum or patient-ethereum-audit-log extension would make sense.
Abbie Watson (Mar 21 2017 at 16:10):
Those fields could probably be renamed; but that's what got the job accomplished. Kudos to Chris Hafey and team; they came up with that.
Grahame Grieve (Mar 21 2017 at 16:11):
I don't understand why you'd extend patient in order to put patient in the blockchain?
Abbie Watson (Mar 21 2017 at 16:14):
I'm a bit fuzzy on that part because I didn't implement it; but it seems like you could do without, but you'd lose the reference and it would get lost in the chain. I certainly wouldn't know how to query the ledger without that info.
Grahame Grieve (Mar 21 2017 at 16:22):
it seems odd to me that a patient has a reference into the chain..? wouldn't the chain index handle that?
Abbie Watson (Mar 21 2017 at 16:38):
We're using a denormalized database (Mongo), so references get duplicated and we run housecleaning methods and event hooks to keep things in sync. It's a pretty typical pattern for our infrastructure to have the reference there. We use the HL7 FHIR schemas directly as our database schemas. I'm sure it could be implemented in a few different ways.
John Moehrke (Mar 21 2017 at 16:39):
I am not clear on the linkage. I would expect the public-key used as identity in blockchain, to be considered one of the Patient.identifier values. This element in FHIR could hold it, and it would be a nice identifier.
Doug Bulleit (Mar 21 2017 at 16:40):
FWIW, the variation of FHIR/blockchain that we're working on does not place PHI Resources themselves in a blockchain; rather only conditioned-permissioned pointers to off-chain (EHRs, IPFS, etc) and/or side-chain (smart-contract-peered pointers to other blockchains) URI/L's
Abbie Watson (Mar 21 2017 at 16:42):
@John Moehrke - I sort of expected the public-key to be in the Patient.identifier as well. But I guess it doesn't need it? ¯\_(ツ)_/¯
John Moehrke (Mar 21 2017 at 16:45):
all depends on what is needed. Pointers need only go one way, if both sides can be queried. More typical of http/REST. So, if the blockchain holds pointers to FHIR objects (protected on a off-chain service), then there is no need to put public key into the FHIR Patient.identifier. It wouldn't hurt... Indeed there might be many blockchain public identifiers that all map to the same patient, to support non-linkability.
John Moehrke (Mar 21 2017 at 16:47):
oh, and if using blockchain public identifiers as pseudonyms in a non-linability mode; then you would NOT want then in the Patient.identifier
John Moehrke (Mar 24 2018 at 20:31):
New article on blockchain in healthcare https://blockchainhealthcaretoday.com/index.php/journal/article/view/24 nothing new but it is well written and easy to read. Mostly targeting executive, not technical people.
Last updated: Apr 12 2022 at 19:14 UTC
