The Trust Triangle: Issuing Disability Certificates as Verifiable Credentials
(I previously wrote about how we could implement data portability in healthcare through the issuance of verifiable credentials. Spoke to a colleague today who shared about a painpoint his father experienced in our healthcare system and how data portability could potentially solve the issue — thought to borrow his idea and expound on the concept of a “trust triangle” in the context of a specific use case in healthcare in order to crystallise our conversation.
But here, I share my own story instead of his, out of respect for his privacy. I gloss over personal details, partly because my memory is hazy, but also because my intention is not to disparage the heroes in our healthcare and social sectors. If you have more ideas for applications in healthcare, please do reach out to me, and I’ll gladly write about them.)
The year was 2016. My father was diagnosed with terminal pancreatic cancer on 9 August, Singapore’s National Day. As the nation marched on in glory, so did our healthcare system, albeit in endless toil. The man was rushed from test laboratory to ward, and we were sent for multiple rounds of clinical and financial counselling. It only took him a few weeks of chemotherapy before he was no longer fully ambulant — fulfilling the clinical definition of being severely disabled.
Singapore has a robust financial support system in terms of disability grants, and my father’s onset of severe disability qualified him for payouts from a particular (now legacy) insurance scheme known as ElderShield.
As a necessary regulatory check on his eligibility, we required a qualified disability assessor to make a trip to my house to verify my father’s extent of disability. Things have improved vastly now, but in those days private insurers were in charge of the administration and there was no central government system available for citizens to access our own disability data. We thus had to rely on the insurers and/or the assessors as custodians of our data — and rightly so, because there was no technical means of us doing so.
My memory is now hazy, but I did remember a lot of painful back-and-forth with the private insurers and the assessors to obtain the necessary documentation for application of other benefits. Even though documents were presented, some welfare organisations also had to verify the documents further by checking back with the original assessor, in case of fraud.
The Trust Triangle
You see, the painpoint revolved very much around trust. Let’s illustrate this with a diagram commonly known as the Trust Triangle:
My applications for further social benefit schemes were approved on the basis of trust in the clinical authority of the assessor, and that I had not committed any fraud. Social workers had no choice but to manually verify that the assessor was indeed certified, and in some cases, had to also call them to verify the details of the disability assessment. If there was system integration, all and well — but system integration is never an easy task.
Suppose however, we had a system where verifiable credentials (in this case, a tamper-proof and verifiable disability certificate) could be issued directly to the patient:
This would have immediately removed the need for any painful back-and-forth between any of the three parties.
How is this trust facilitated without any system integration, you ask? Good question.
Understanding the Trust Network
The decentralised trust triangle diagram above omits an important component — at the heart of this facilitation of trust is the presence of a Verifiable Data Registry where issuance and checks can be conducted.
Probably a little bit too much for those uninitiated to the concept of decentralisation, so let’s take a step back and unpack some concepts without going too much into technical detail:
- The three parties in the trust network can be broken down into their respective roles: (a) issuer (i.e. assessor), (b) holder (i.e. patient) and (c) verifier (i.e. social assistance agencies)
- The issuer issues verifiable credentials (i.e. disability certificates) to the holder, which is then verified by the verifier when presented by the holder, presumably to qualify for some benefit (e.g. subsidies)
- These verifiable credentials are decentralised (i.e. any approved assessor may issue them, no need for central government issuance) and cryptographically secure (i.e. tamper-proof) — (for the experts, verifiable credentials must present two other properties, but let’s suspend this for now)
- A decentralised identifier (ID) is simply a hashcode (i.e. string of characters) with an embedded method for interpreting the hashcode in order to verify your identity and status as specified in the verifiable credential
- A verifiable data registry, contrary to what many people think, need not be a blockchain. It could well be a simple public (but secured) web database. Of course, blockchains have their own benefits.
Notice how all three parties interact independently with the verifiable data registry in order to create trust, and it is this registry that mediates the process of trust.
The Particular Instance of Disability Certifications
Circling back, this model of trust has an additional feature that makes it very useful for more complex situations commonly presenting in this particular use case of disability certifications. That is, the feature of delegated guardianship:
- For example, instead of just making the person with disability the subject of the credential, we could also make the guardianship the subject of the credential — this comes in very useful because there are many cases in caregiving where the person may not have the ability to utilise or control their own credentials (e.g. children, persons with dementia).
- In fact, we could go further because the holder does not necessarily need to be a person, because verifiable credentials can be issued to organisations (or even objects, for that matter). This enables digitalised proxy interactions which were not possible before, even with the internet.
We could go on — but these will be stories for another day.
