Effecting Data Portability in Our Healthcare Ecosystem: A Data Standards Problem

(I previously wrote about how the concept of data portability could ease the interoperability issue, but was rather silent on a possible mechanism. So indulge me with much patience as I try to crystallise my thoughts on how we can take it further. Again, this article only touches on what I’ve conceptualised thus far, so comments are welcome to take my thought processes further.)

Suppose we believe in putting data in the hands of our patients. How do we even begin to implement such an idea? I’m not talking about the personal data and privacy regulations that have to be formulated, but more of the underlying tech.

Let’s see if we can formulate a solution together in this post. I’ll be careful to lay down my premises, so the reader can tweak the solution according to his own premises if he wishes.

Starting Our Journey: Digital Standards for Healthcare Credential Issuance

We start with the premise that all healthcare credentials are data documents rightfully owned by each patient. However, patients come into ownership of these data through a process of issuance by an approved healthcare provider. For example, your blood test results rightfully belong to you, although they had to be administered and issued by an approved medical institution.

To prove the provenance (by that, I mean a combination of who the results belong to, and whom the results were issued by) of the healthcare credentials, some sort of signatory framework is required for issuance. In common parlance, we refer to this framework as a set of “digital standards”.

Preferably, the digital standards should also be in line with international healthcare data standards, such as the Fast Healthcare Interoperability Resources (FHIR).

Making It Clear: OpenAttestation as an Example of Digital Standards

It’s around this point in time that I lost most of my friends in conversation, so I think it’s worth breaking it down further what digital standards are in practice. What better way than to use an actual example? OpenAttestation!

OpenAttestation (OA) is an example of a digital signatory framework, under which any document (i.e. healthcare credential) can be issued in a machine-readable format, that is also tamper-proof and verifiable. These are the exact properties that make it so useful for healthcare.

Under OA, we create and issue documents as a “Verifiable Document File”, also called an OA document. These documents are machine-readable because they are in the form of a .json file, according to some specific schema (click here if you’re interested to see what a FHIR-aligned OA schema looks like). These files contain the healthcare credentials, but also contain important metadata such as:

• the issuer’s identity (i.e. the healthcare institution)
• document rendering information (i.e. instructions on how to format it into a nice human-readable document, like a pdf for example)
• document store smart contract

The smart contract is of essence here — it’s essentially a proof of issuance that is uploaded as an actual smart contract on the Ethereum blockchain. With this smart contract, you essentially have an immutable record on the blockchain for anyone to verify the issuance of the document, and to see if it has been tampered with or not.

The expert can correct me if I’m wrong, but I believe OA essentially creates hashes from a batch of documents, and then creates another hash out of all these hashes to form a Merkle root. This forms the basis of the smart contract, which is then stored on the blockchain.

So how do we use the OA document and present our healthcare credentials in practice? Well, here’s a simple workflow diagram provided by OA:

OA Workflow

• Your healthcare credentials are issued in the form of an OA file, in .json format
• If a healthcare provider requests for your credentials, and if you so consent, you can send them your OA file in any way you wish (e.g. email)
• The provider can tap on a decentralised renderer, which is actually a website that transforms an OA file into some sort of human-readable format. (Remember how the OA file contains instructions for doing this?)

So two things to point out here that initiates data portability:

1. Notice how the healthcare credential is in an entirely machine readable format, aligned to an acceptable healthcare data standard. This means that the healthcare provider, if it so wishes, may obtain the corresponding consent from you to ingest your data into its own electronic health record system (which should be compliant with FHIR, right?).
2. To the medical practitioner, the OA file is probably useless. But fret not, there’s no need to write extra code to format the OA file into something readable, because of the decentralised renderer.

Next Step: Who’s Doing the Issuance?

All and well. But who’s going to be helping the healthcare provider with the issuance of such digital healthcare credentials? Surely we don’t expect the doctors, nurses or the provider to build such capabilities?

Fret not, there’s always some sort of Software-as-a-Service (SaaS) provider out there who can help with the issuance. You see, currently there are quite a few such SaaS providers who have already successfully integrated with a significant number of healthcare providers.

And by integration, I mean the process of issuance is entirely automated through APIs (or some sort of equivalent data transfer).

These SaaS providers provide the service of issuing the healthcare credentials as a OA document based on an agreed input from the healthcare provider. So workflow wise, nothing quite changes for the healthcare provider other than the fact that there is some backend data piping.

And for the patient? Well, nothing as well! They receive their credentials as if they were issued by the healthcare provider, seamless.

Wait a Minute: How Will Patients Receive and Store Their Data? How About Healthcare Providers Who Wish to Receive and Verify Data?

Good question. For starters, a bare-bones solution would be simply to issue the healthcare credentials through email.

Insecure you say? I also say. That’s why preferably, we require some form of digital wallets to store, organise, retrieve and eventually help send the documents to healthcare providers.

Again, these wallets can be implemented on the healthcare providers’ end to receive credential transfers and verify the credentials against the blockchain. After all, it is a Web 3.0 world.

More sophisticated wallets can of course code in the exchange of consent as well, but that’s a story for another day.

Open Source Means… Open Fraud Right?

Ah hah! If you’re doing everything open-source, then surely any illegal sub-standard healthcare provider out there can also issue such credentials, right? How will you protect the integrity of the healthcare credential records?

Good question. Here’s where the government will need to step in. You see, there is no longer any central authority in charge of creating a central data repository. This should theoretically free up central authorities (not necessarily the government, but it could be trusted healthcare organisations) to maintain a backend list of official approved healthcare providers who are recognised practitioners.

Actually, you don’t even need one central authority, you could have a few central authorities even, each creating some kind of backend directory of whitelisted healthcare providers, but all merged together.

It’s then a simple implementation on the wallet end to include this directory for further verification, that the healthcare credential was indeed issued by a recognised provider.

That’s about all the time I have tonight. Adios!