Stream: blockchain
Topic: Blockchain use case
Grahame Grieve (Mar 27 2019 at 03:36):
Today a block chain company put a proposal to me which I'll describe here in general to see what people think:
- consumers are provided with a FHIR server end point
- any resources added to the end-point are hashed and the hash and provenance are stored in a block chain
- the user can grant access to their data to an algorthm, which can access both the FHIR Server (to see the consumer's healthcare data) and the block chain (so they know that the data is authentic)
- any data access by the algorithm will be logged in the blockchain
- the algorithm can present the user with it's findings (some kind of consumer orientated CDS). The algorithm can't exfiltrate data to some other source (unless the user says they can?)
Grahame Grieve (Mar 27 2019 at 03:36):
what do people think?
Peter Jordan (Mar 27 2019 at 04:10):
Might work for a fit and healthy consumer with a relatively small and immutable digital health record. :unamused:
Lloyd McKenzie (Mar 27 2019 at 06:28):
Do we expect knowing the data is authentic is a problem? The patient is still trusting the algorithm to log the accesses. And if they don't like the accesses, there's not much they can do about it. I don't really understand where block chain is really helping solve any problems here.
Grahame Grieve (Mar 27 2019 at 07:10):
My opinion was that it was actually creating problems, and not solving any that actually needed solving. But I thought I'd check....
John Moehrke (Mar 27 2019 at 12:43):
As you describe it, there is some key trust issues missing. This becomes more clear when you start with a persona of someone that has been given authority to access the data. These persona do need some assurances that the data has not been manipulated by the patient, or other intermediaries. That the data they are looking at is the data the original author published. Thus the cryptographic signature must initiate at the author.
As you describe, the hash is by the infrastructure. Thus the patient may have manipulated it. Or the infrastructure may have manipulated it prior to hash.
Fixing this requires all authors to publish their Provenance into the blockchain. Which is a problem. I have outlined that kind of a use of blockchain as a "Blockchain Provenance Service" https://healthcaresecprivacy.blogspot.com/2019/03/blockchain-provenance-service.html
John Moehrke (Mar 27 2019 at 12:44):
They have just defined a Personally controlled repository (a good thing) that has a flashy blockchain knob that adds no value.
John Moehrke (Mar 27 2019 at 12:47):
Optimist says that the blockchain would provide protection of changes from the time the blockchain entry was created. Thus it is a time-stamp-service. That is there are provable and trustable timestamps.
Grahame Grieve (Mar 27 2019 at 19:02):
These persona do need some assurances that the data has not been manipulated by the patient, or other intermediaries
Why? Does the patient have the right to correct errors before running any algorithms? Or must they accept flawed outcomes because of some reason?
Abbie Watson (Mar 28 2019 at 06:05):
This is very similar to what we implemented and presented. The problem we ran into was the "algorithm which can access the FHIR Server" part. In short, for the architecture to work, the FHIR Server has to recognize "the algorithm" as being an OAuth equivalent, and have it registered as being able to offer up an OAuth token equivalent. That's great in theory, and easy for an architecture to proclaim that the FHIR Server will support their blockchain token. In practice, our FHIR Server vendor was like 'you want us to do what?' and basically laughed at/ignored the request. That phrase "algorithm which can access the FHIR Server" basically involves extending the entire SMART on FHIR security model.
John Moehrke (Mar 28 2019 at 15:54):
These persona do need some assurances that the data has not been manipulated by the patient, or other intermediaries
Why? Does the patient have the right to correct errors before running any algorithms? Or must they accept flawed outcomes because of some reason?
If the patient changes the data, then they must also indicate THEY are the author. If they present content as being authored by John, then they must keep the data as authored by John. Are you saying that is not true? This is Medical-Records 101. This is Provenance.
John Moehrke (Mar 28 2019 at 15:59):
The patient absolutely has the right to declare they disagree, but that is a new piece of data authored by that patient. Security geeks (and legal folk) enable appropriate things, but also prevent inappropriate things. Not all patients are honest, not all clinicians are honest, not all payers are honest, etc... We must think about the abuse scenarios, not just the happy-path. No good reason to have security/privacy/safety if everyone only did the right thing.
Grahame Grieve (Mar 28 2019 at 18:27):
my contention would be that the difference you are drawing only matters if the data is going to ex-filtrated elsewhere and used as the basis for medical decision making
Lloyd McKenzie (Mar 28 2019 at 18:32):
It probably matters a bit for secondary use, though whether you should trust data corrected by the patient less or more would itself be an interesting research topic...
Nick Hatt (Mar 28 2019 at 19:39):
The patient is still trusting the algorithm to log the accesses. And if they don't like the accesses, there's not much they can do about it.
That's the real trust problem to solve. Put AuditEvent on the blockchain so patients have nonrepudiation.
You still have to trust the FHIR Server. Like really, really, trust that AuditEvent and the Resource request are atomic.
Grahame Grieve (Mar 28 2019 at 19:58):
right. there's lots of trust required here - but not in the way that blockchain introduces, so far as I can see
John Moehrke (Mar 28 2019 at 20:10):
what is the reason to have blockchain watching the data if not to provide proof that the data is what it was?
Grahame Grieve (Mar 28 2019 at 20:11):
because you can say you use blockchain?
Gene Vayngrib (Apr 04 2019 at 12:10):
Great discussion! Since I am the founder of the company that proposed the solution to Grahame, let me offer a couple of clarifications to Grahame's great and concise summary of our proposal. First of all, our intention is to create a strictly personal cloud-based extension of a mobile phone. We call it MyCloud, to differentiate it from Apple's iCloud. Unlike with iCloud, this is under a person's cloud account, and enjoys the same isolation level as banks enjoy when they use the public cloud. Unlike iCloud, a person will be able to use apps to operate on their data. The model will be a mix of installed apps, like installed on iPhone or Android, and web-apps, apps that get downloaded, execute and go away. Unlike a browser on your PC and the phone, MyCloud is an always on server with stable bandwidth, fully elastic data storage, database, ompute etc. It uses 3rd gen cloud tech to make it zero maintenance and fully automatic scaling, which at the same time using highly granular cloud accounting for all the resource usage and access. This is needed not just for security but for offsetting charges for use of resources to the third party, e.g. algo author. This MyCloud will be an FHIR server as well. The beauty is, majority of what we do is open source. Just go to https://github.com/tradle and explore.
We are new to health space, so forgive our initial ignorance, and we will strive to rectify it by diving deep. Here is how we are thinking about a personal FHIR server, and we welcome critical feedback and offers of collaboration.
-
Identity of a person, organization, device, app, etc. that enters, generates or modifies any type of data is established via a decentralized PKI, assisted with the blockchain. This is the foundation on which we have built financial grade identity system (KYC).
-
Any element of data is signed with the originating identity. It is also counter-signed by the recipient for non-repudiation and provenance.
-
Data is versioned, with all prior versions available for historical purposes and fraud analysis. Hence data from health care provider that had an error is preserved, and the edit by the person to correct it, is preserved.
-
Ontology: every data item has a proper type, corresponding to FHIR. Data Type is a convenient container to attach security policies, presentation preferences, etc. (we have used this with great success in very complex multi-party hierarchical and web-of-data supply chain scenarios). If outcome of the discussion is positive and business model is confirmed, we would implement this personal FHIR server based on how all the automation we have in place already for handling ontology based system for finance. This system is based on 3rd gen cloud, using 100% Software Defined Architecture, which includes messaging, database, media storage, change events, generic GraphQL API for any data, function as a service, REST endpoints. All with 100% automatic scaling.
-
Security policy on who has the right to edit a specific type of data can be custom, and depend on origin (e.g. no editing the EKG) and who it was shared with.
-
Every data element is sealed on the blockchain. We use the term seal, as it is not a hash but a cryptographic product that allows to achieve expected immutability and secure timestamping, while avoiding mass surveillance with large anonymity pools and making seals opaque and inconspicuous. Importantly, seals support data versioning, and partial sharing (sharing a subset of fields, while proving that they are part of a larger set).
-
Curation of algos that visit personal FHIR server will start via one or more trusted third-parties (and will later be enhanced by the use of private smart contract like Enigma.co, which will allow expanded curation pool and a proof that algo was not tampered with). All curation statements about an algo are recorded, signed and sealed on blockchain as well. Cloud-based monitoring tools log all actions of the algo, and can be independently monitored, auditing for misbehavior, without giving the auditor access to the underlying data. Identity of the algo author is known upfront and any negligence or malfeasance will be reputationally damaging.
Grahame Grieve (Apr 04 2019 at 12:41):
so a FHIR server with a blochain on the side... maybe. how do I trust the FHIR server not to just re-generate the blockchain?
Grahame Grieve (Apr 04 2019 at 12:42):
but other than that... sounds like a great idea to build the actual service (and we do have a Provenance resource that we use for tracking the content). We just trust the service (at present, at least)
Gene Vayngrib (Apr 04 2019 at 12:57):
so a FHIR server with a blochain on the side... maybe.
sure, but consider any data element linking to prior data elements, and pointing to related data elements. This forms both a chain-of-data and a web-of-data that can be validated both for who produced them, when and what prior edits were made. This blockchain on-a-side becomes critical since the algo which is visiting the data and charging its owner for producing insights may be liable for making bad decisions, and thus needs to ensure itself that it can rely on the data. Any fault in my logic?
how do I trust the FHIR server not to just re-generate the blockchain?
Can you clarify? I am not sure what you mean by re-generate the blockchain.
Grahame Grieve (Apr 04 2019 at 20:32):
I'm not sure what crypto set up you have to ensure that a blockchain consumer can verify that the blockchain is reliable (e.g. hasn't been rebuilt by the source of the data) without leaking patient's data
Grahame Grieve (Apr 04 2019 at 20:33):
I think the trust is in the server provider, and it's not obvious to me how the block chain builds on that
Last updated: Apr 12 2022 at 19:14 UTC
