Let’s Tokenize Health Care …

Sometime, soon, we need to switch off our old 20th Century digital world, and move to a world that properly integrates trust, and where we…

Photo by Hush Naidoo Jade Photography on Unsplash

Tokenizing Health Care …

Sometime, soon, we need to switch off our old 20th Century digital world, and move to a world that properly integrates trust, and where we can instantly audit large and complex infrastructures.

And so, a new world is being built. With this we have fungible tokens (ERC-20) and non-fungible tokens (NFTs — ERC-721). With a fungible token we have the same token, and where each token will have the same value. This can be likened to money, and where we issue a number of bank notes. On the other hand we have NFTs, and where each one is unique, and can be associated with an asset or physical entity. Overall, it is possible to transfer ERC-20 tokens, but we cannot duplicate or destroy an ERC-721 token.

If you want to create your own ERC-20 token, try here:

https://asecuritysite.com/ethereum/ethereum03

Building a tokenized health care system

So let’s say I want to redesign health care services? How would we even start to do it? Well, let’s keep it simple, and where we have some funders (such as FrankNHS, PeggyCouncil and MalloryGov), and some health care providers (such as AliceCare and BobCare):

Within the Ethereum blockchain we can then record transactions and run smart contracts. These will allow us to run DApps (decentralized applications) and which can support the running of the infrastructure in return for some payment (Ether). A DApp can also create tokens for new currencies, shares in a company, or even to prove the ownership of an asset. But, if I bought a car from someone else, how would they send me the token? Well, that’s where ERC-20 tokens come in. These allow for the sharing, transfer and the storage of tokens.

The ERC-20 token

ERC-20 tokens are supported by the whole of the Ethereum infrastructure and can be easily traded. They support a number of mandatory functions:

  • totalSupply. This function is the total number of ERC-20 tokens that have been created.
  • balanceOf. This function identifies the number of tokens that a given address has in its account.
  • transfer. This function supports the transfer of tokens to a defined user address.
  • transferFrom. This function allows a user to transfer tokens to another user.
  • approve. This function checks that a transaction is valid, based on the supply of token.
  • allowance. This function checks if a user has enough funds in their account for a transaction.

We can then support optional functions:

  • Token Name. This is the name that the token will be defined as.
  • Symbol. This is the symbol that the token will use.
  • Decimal. This is the number of decimal places to be used for any transactions.

Meet a Health Token

So let’s say I create a ScotlandHealth token, and give it the name of SCH. I then create 1,000 tokens for all the health work to be undertaken in Scotland. For this we will have three funders — FrankNHS, PeggyCouncil, and MalloryGov - and five care providers — BobCare, AliceCare, EveCare, TrentCare and CarolCare. Now, let’s say the budget for the year is to allocate 500 SCH tokens to NHS, 300 SCH to Council and 200 SCH to Government. In order to pay for work done, we would then run the transfer function, and perform these allocations to the Ethereum addresses defined by them. Initially, without any transfers, we can view the tokens in each account with the balanceOf function and we should see:

  • NHS: 500 SCH
  • Council: 300 SCH
  • Government: 200 SCH
  • BobCare: 0 SCH

Each of these entities then defines a smart contract for care services:

In this case, BobCare now agrees a contract with PeggyCouncil to change bandages for Alice — who lives in Edinburgh — and at a rate of 2.5 SCH per hour. The staff at BobCare are at a novice level, so the payment will be 2.5 SCH for one hour’s work. Now, once BobCare proves that they have changed Alice’s bandages, PeggCouncil then uses the transferFrom function to move the funds to BobCare.

When can then run the balanceOf function again to see:

  • NHS: 500 SCH
  • Council: 297.5 SCH
  • Government: 200 SCH
  • BobCare: 2.5 SCH

But what happens when BobCare tries to transfer 3.0 SCH to AliceCare (and thus overspends on their wallet). Well, the approve function will check the transaction against all the tokens that have been issued, in order to check that there are no missing tokens or no new tokens being added. This function will also make sure that there are always 1,000 SCH tokens, and not more or less.

And so, we have designed a health care system which does need fiat currency, but where all of the transactions are verifiable. When BobCare wants to convert the tokens into fiat currency, they will go to an exchange server run by FrankNHS, PeggyCouncil, and MalloryGov, and can instantly covert back into cash. The tokens will then be re-allocated back to the funders.

Some advantages

Here are some advantages:

It is thus not possible to conduct fraud on the system, as no-one can create or delete tokens. Along with this, every time there is a transfer, the allowance function is used to check that the user has enough tokens in their account to transfer to another user, and will cancel the transaction if the account does not contain at least the amount to be transferred.

It is thus not possible to overspend on your account. With ERC-20, we try to standardize the usage of tokens so that the functions are clearly defined. A user’s wallet can then just accept these tokens, without having to adopt different formats. So now, each year our health care system can create new tokens, and distribute them to the care funders. In this way, we can create the whole of our health care systems of tokenization.

At any given point in time, we will know exactly, all of the transactions that have ever been made. And, if we wanted we could audit to the second. All of the entities within the ecosystem would know exactly what their funds were. When required, we can then put a value of the tokens and can be covered into a fiat currency, and where the ownership of the token is then pegged to a financial gain. It is probably at this point that the HMRC would be interested, and would be looking for tax returns on the gain. While in the system, the tokens could be traded without actually requiring anything to be taxed. In this way, we could codify our health care infrastructure and create smart contracts which defined the payments from funders to providers:

zkERC20: Confidential Token Standard

But, you say, what about GDPR? What about privacy? What if I don’t want my identity to be seen for the payments that I received? Well, some new code has been developed which overcomes this problem, and uses zero-knowledge proof (ZKP) to hide the details of the transaction, but still allow the system to check the details. So meet zkERC20 [here]. In this way we can preserve the privacy of assets transferred or the details of the payments. With this, these tokens do not have a balance, but have a value represented by notes which contain an encrypted value.

Within the zkERC20 token, we use a one-time stealth address to receive the ownership of a token. As it is a one-time Ethereum address, it cannot be traced back or forward into the future. The payment of the Gas for the transaction can then be made from the address which is creating the one time address, and this divorces the payment of transaction costs and the details on the ledger, from the actual token itself.

Conclusions

Over the next few months, we will be showing off our full vision at a number of conference events, so, hopefully, you can catch-up with us. So how would this benefit the provision of our public service?

  • Smart contracts define the details of the payments, and which can then be automatically triggered for payments when key deliverables happen.
  • Every transaction is digitally signed and checked before it is enacted.
  • Complete auditing of the whole system at any given time, and where we can view all the transactions that were made.
  • Only tokens are traded, so there is a limited liability on financial transactions.
  • An exchange converts into a financial output, and where we can audit and verify every transaction, and then for financial return.
  • If we use zkERC20, we can anonymise transactions.

ERC20 makes the building of new ecosystems more scaleable, and zkERC20 could address concerns around privacy. If you want to create your own ERC-20 token, try here:

https://asecuritysite.com/ethereum/ethereum03