11E/ Controlling your medical data via DIDComm - discussion and feedback on our system architecture

From IIW

Controlling your medical data via DIDComm - discussion and feedback on our system architecture

Wednesday 11E

Convener: Elias Strehle (elias@circulartree.com)

Notes-taker(s): Elias Strehle

Tags for the session - technology discussed/ideas considered:

DIDComm, Hyperledger Aries, Hyperledger Indy, Medical Data

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps

Link to the slide deck

Some edge cases to think of when considering patient control over medical data:

  • Some psychiatric patients are not allowed to see their own diagnosis

  • Some infectious diseases MUST be reported to public health authorities, even against the patient's will

  • Physicians might want/need to see medical data that the patient is unwilling to share

We want to send files (possibly images or even videos) across DIDComm. Does that make sense?

  • It's already possible to send attachments via DIDComm

  • Becomes impractical for large files on phones, unsurprisingly

  • Possible alternative: Just pass File URL + Access token + Hash via DIDComm


  • How to make sure the recipient understands what they get and gets what they expect?

  • This is very hard, medical data is extremely diverse and there are a lot of competing standards

  • Our project does not have a great answer to this yet, but we hope to get communication out of the way quickly so we can work on (semantic) interoperability as soon as possible

Do we use VCs?

  • Currently not, authentication relies on personal contact during peer-to-peer registration

  • It is already clear, though, that this is not feasible or trustworthy enough for all use cases

  • VCs for authentication will have to become part of the solution

  • VCs for file hashes might also be interesting to establish trust on data

  • The Hashlink standard might be useful for this

  • Is Hashlink already part of DIDComm? So far only as attribute of a credential

Idea: One advantage of the system is that you can discover the medical data that exists via DIDComm:

  • Connecting with medical provider and then seeing a list of available data is a great alternative to filling out annoying paper forms

  • A search functionality would be really cool ("Does anyone have an x-ray of my arm?")

  • But as soon as we need semantic interoperability this gets extremely complex

As a patient, how can I trust the medical provider?

  • Malicious software/faked QR codes could be a problem

  • This is where VCs come in from an identity perspective

Have you tried embedded versions for medical devices?

  • No, the project hasn't explored that

  • Can we make pacemakers communicate directly with physicians instead of manufacturers? How would we integrate that use case?

  • Very complex as there are a lot of different devices and many of them have strong constraints on computation/memory/storage/availability

Use case to consider: How can emergency responders get access to critical medical data?

From a medical provider's perspective: Who should have the DID - the institution or its employees?

  • Both are possible, depends on strength of relationship (e.g., employee DID might make a lot of sense for psychotherapist) and use case requirements

  • Legal framework and requirements likely vary a lot from country to country

Who in the system should have a public DID?

  • Usually unproblematic for institutions, i.e., medical providers

  • Peer DIDs for private persons can make a lot of sense

  • Indeed, it would be very problematic to have a "super-ID" for a patient, this might not be GDPR compliant

  • However, this makes it harder to link VCs for authentication (subject binding)

  • "Subject binding"

  • If a patient's phone is stolen, using peer DIDs only would still allow them to block access to medical data from that phone: This requires a secure backup to cancel the keys on the stolen device

What are potential business models for mediators/ledger operators?

  • No big amount of trust towards mediators required, they see only encrypted data

  • Often, the app provider could also provides the mediator

  • Mediators for medical institutions or practitioners could probably cost money, or might be provided by professional associations/schools/government

  • Note: There are open source standards for the relationship between mobile app and mediator, but it's also possible to do something on your own without losing interoperability with the rest of the system