Best approach for sharing and managing access to Personal Health Information

[robot5x]

Hi all -

I’m really new to Holochain, but have just finished all the DevCamp 7 content after @bear kindly gave me access (and I have to say I was really inspired by all the work and effort that went into that, really amazing job).

I work for a healthcare non-profit in New Zealand, and want to build a small-scale proof of concept for PhD research I am conducting on decentralised technologies, and how they can be used in healthcare to support Data Sovereignty (especially Indigenous Data Sovereignty). The core requirements are:

• dynamic and detailed access control of a user’s data (who I share my data with)
• logging and auditing of access (who has accessed my data and when).

The kind of basic workflow I have in mind is:

• Bob generates data which is posted to their source chain
• This data is private and can only be accessed by Bob
• Bob decides to share it with Dr Alice
• Dr Alice can now access Bob’s data
• Bob can withdraw that capability grant any time and stop Dr Alice’s access
• Bob can view how Dr Alice has accessed their data.

There’s lots of other things I want to throw in here (connecting wearables/smart devices, segmenting health data by type - eg. medications vs diagnoses - so that access can be granted selectively to different kinds of data, and a ‘break glass’ access facility for emergencies) but the above is most of the basics.

I would be really grateful for any architectural or design advice from members of the community, since it seems there are a couple of different patterns which could achieve this.

For example, @e-nastasia in DevCamp 7 session 10 used sharing of health data as an example of using capability token to provide access to a users source chain. The big downside seems to be that this sharing will break if Bob’s device is offline.

Conversely, in this thread, @pauldaoust suggests the concept of a ‘private DHT’, ie. to put your private data into a separate DHT, but only allow access to your trusted users you are sharing with. This would allow your ‘trusted users’ to distribute your data between them, so that they can all access even when you’re offline.

However, in reality, a decentralised health data hApp like this could have a large number of users sharing their data with very few people (ie a user may only ever share with their GP, or another family member). So, you will lose some advantages in redundancy offered by a DHT if it is built like a series of private DHTs.

It seems like the design options are:

1. A single DHT where users selectively issue/revoke capability tokens to manage access to their data (but where data cannot be accessed if the user is offline),
2. A series of ‘Private DHTs’ where the data is available on the DHT but only trusted users are able to access it,
3. Or is there a third way?

Thanks a lot for your advice! alex

[thedavidmeister]

one thing to consider is whether you trust encryption and whether you could achieve additional data redundancy on a semi-trusted network that handles encrypted data in a non-functional way - this might require a ‘fair use’ policy embedded in validation rules to throttle data coming in, or just some degree of trust between users on the backup DHT that it won’t be abused by participants

encryption can be done either with a ‘shared secret’ where anyone with the password can decrypt, or by keypairs so that owners of specific public keys can decrypt it

that said:

• private entries have zero redundancy because they are always protected by capability tokens and never broadcast, this is like a traditional client/server model
• agents are always responsible for storage integrity of their own source chain, and making backups of their source chain, the DHT doesn’t remove the need for the author to protect their own data
• DHT redundancy is about other agents being able to access shared data from authorities without the author
• ‘private DHTs’ with shared data within that private network increase redundancy relative to private entries because you go from zero to more-than-zero redundancy
• you can use remote calls and capability tokens to directly share private entries between agents who trust each other, and then these agents can have separate capability tokens to delegate access to semi-trusted users (creating your own redundancy/security model that better fits your context-specific workflows) - e.g. a patient can copy their data to a GP’s server and then the GP can forward limited access to this data to an insurance company until the patient asks the GP to revoke that access, etc.

[robot5x]

thanks @thedavidmeister! That’s really interesting.

I’m particularly interested in the encryption approach - that seems to strike a good balance between effective use of the DHT and privacy. In ‘real life’ that may be a risky approach (especially with quantum computing on the horizon) to store sensitive encrypted data in a public DHT (or blockchain, for that matter), but it would be a great demo solution for my research.

Is there any available pattern or documentation showing how this could be done?
In fact, taking one step back, is there a good example somewhere of using capability tokens in holochain?

Thanks a lot - alex.

[thedavidmeister]

@robot5x this is the test wasm for capabilities that covers the basics - https://github.com/holochain/holochain/blob/develop/crates/test_utils/wasm/wasm_workspace/capability/src/lib.rs

quantum computing only impacts certain encryption, for example AES256 should be resistant

you can combine all the techniques discussed above, it’s best not to think in terms of ‘i’m using encryption’ or ‘i’m using private networks’ - a real world application is a complex system and different components will work best with different tradeoffs

[robot5x]

thanks again @thedavidmeister and sorry not to thank you sooner - I’m trying to learn, but not familiar enough with rust and still some holochain concepts right now to pick up and run with this…

I wondered if anyone can give me some pointers about how I might for example extend the microblog tutorial to use capability tokens? That gave me a good overview of some basic functionality - and now, to help me understand how capability tokens fit in, it would be interesting to see how you could ‘authorise’ the microblog content for certain users.

[thedavidmeister]

@robot5x whenever someone does a remote call they need to provide a cap token

the person being called needs to have previously committed a cap grant with that token in it that corresponds to the function being called (and optionally the pubkey of the caller)

the person being called can also revoke grants which revokes access for that token

the example i linked shows how someone can create a grant, send someone else the token for that grant, then that person can use the token to ‘dial back’ to the first person and call functions associated with that grant

[robot5x]

ok thanks, that’s helpful. I’ll have a play with that and see how far I can get. I’ll start a new topic for when I get stuck.