Redesign the Provision of Health Care Funding For a 21st Century within a Tokenized World

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…

The Provision of Health Care Funding For a 21st Century within a Tokenized World?

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 audit large and complex infrastructures by the minute (rather than waiting for months to know the state of our accounts).

It will be a world which doesn’t involve pushing paper-based contracts, and one which won’t have financial transactions based on 16 digit credit card details and sort codes. It will be a seamlessly integrated world, and where tokens are traded and exchanged. The ownership of an asset, too, will be defined with whoever as the required signed asset token. Services will be provided through the exchange of tokens, and where the owner of the token infrastructure can issue new ones.

Our world will become a whole lot more trusted.

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

Meet Ethereum and ERC-20 tokens

Within the Ethereum blockchain we can record transactions and run smart contracts. These things 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 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 storage of tokens.

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.

So let’s say I create a ScotlandHealth token, and give it the name of SCH, and I create 1,000 tokens for health work to be undertaken in Scotland. We then might have three funders (FrankNHS, PeggyCouncil, and MalloryGov) and five care providers (BobCare, AliceCare, EveCare, TrentCare and CarolCare). Let’s say the budget for the year is to allocate 500 SCH tokens to NHS, 300 to Council and 200 to Government. We would then run the transfer function, and perform these allocations to the Ethereum addresses defined by them. When we conduct the balanceOf function 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 Scotland:

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 we conduct the balanceOf function we should 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. 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 make sure that there are always 1,000 SCH tokens, and not more or less.

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.