Why I registered my vaccines on the blockchain

And why you should too

Recently, before going on a trip, it was suggested to me that I schedule an appointment with a doctor to check if I would need any vaccines. Upon arriving, I was asked:

“So what vaccines have you already taken?”

The question seems to be an easy one. All I need to do is check my vaccination card. However, there is a problem. I am currently living in my third country, where I have no medical records, and have previously taken vaccines in two different countries. With me, I am carrying my Brazilian vaccination card, but the card is merely a small sheet of paper with hand-written records of my vaccines. The card is also falling to pieces.

The little piece of paper I have kept for over two decades. Pen in the picture for size comparison.

As such, after being told I would typically need four vaccines for my trip, I simply said: “Give me all the ones that won’t kill me if I take them twice”. Eventually, I took three vaccines, and a record was created in the system. I now have my vaccination record split between two separate online databases and a tiny piece of paper.

This event got me wondering if there was a better way. Not necessarily for everyone, just for me, really. What if I could always have access to my record, from anywhere? Well, one thing I could do is set up a database and put all my vaccines there. I could then create an app or website to interact with this database and display the information to me through a nice-to-look-at front-end. However, in doing so, I would be subject to some problems:

  • Lack of immutability: Traditional databases allow for users to remove and change data previously stored. Hence, a person who gained access to the database could erase my records or modify them without my knowledge. Since I cannot remember all the records (which is why I’m making this article in the first place), a modification might even go unnoticed, and lead to drastic consequences (i.e. me dying from a vaccine overdose).
  • Hosting: To access my database, I would need to host it somehow. Thus, I must trust my provider and hope that the data will always be accessible when I need it, and, depending on my demands, I might need to pay for this service to keep it running.
  • Maintenance: To ensure security and availability, I would need to maintain, to some degree, an active oversight over my database and its hosting. Also, if a problem arises, I will need to fix it to ensure my application continues running.

Therefore, in order to mitigate these problems, I decided to register my vaccines on the Ethereum blockchain. I created a simple smart contract and website, and it was much easier than you might think. To further understand my motivation for doing this, you can read “Harnessing the full potential of blockchain technology”.

Step 1: Smart Contract

I started by building a smart contract in Solidity which would allow me to register and retrieve data, in a way that only I could perform those functions.

To save on gas costs, I made the contract as simple as possible. If you are unable to comprehend the code, it essentially allows three pre-defined Ethereum addresses to “register data” and “get data” (i.e. write what vaccines I’ve taken and see those records). These three addresses are owned by me.

So that’s it. But before we proceed, a couple of considerations:

  • I accounted for the fact that I may lose access to one address so I defined three addresses that are allowed to write and read data. I did not, however, account for someone gaining access to one of my accounts and adding new records. Again, I tried to keep this as simple as possible. In the eventuality that I notice a registration that was not done by me, I can either stop using the contract or instruct my front-end to ignore specific registrations when displaying the records to me. But most importantly, I can be aware that tampering has occurred, and the person will not be able to delete data, only add new data.
  • I could have easily created a function to add new vaccines individually and then push them to an array or use a struct with the necessary parameters. However, as this is merely experimental, I decided to save on costs by sorting through the separate vaccines in JavaScript, instead of implementing that functionality in Solidity. This will become clearer in the following section.
  • Even though getData has the modifier onlyOwners, meaning that the function cannot be called by others, this does not mean that the data stored is private. All information stored on the Ethereum blockchain can be viewed by others.
  • The function dataLength is included as it is useful for optimising my JavaScript loops.

Step 2: JavaScript

To cut down on the costs of publishing the smart contract and calling its functions as much as possible, I opted for a simple structure, and left all the “heavy work” to be done by JavaScript on the front-end. Essentially, the more complex the smart contract is, the more computing power it demands from the network, and thus, the more it will cost to execute. Therefore, I decided to use the smart contract only to store data in its most basic form, and perform all the processing necessary on the user’s machine, through JS.

I will not display my code in this article, but those interested can see it here.

What I did was ensure that, when registering my records through the smart contract, I wrote it in a specific format, shown below:

“Date, Name of Vaccine, Number of the Vaccine, Additional Info |”

Date refers to the date when the vaccine was taken and name refers to the disease it protects against. “Number of the vaccine” relates to vaccines that must be taken more than once, and additional info allows me to add metadata such as where I took it, or if I had any side-effects.

A registration will therefore look something like this:

“22/01/2018, Hepatitis B, 3, Finland | 16/04/2018, Tetanus, 1, UK”

With this method, I can register all my vaccines at once with only one function call. It is important to note that the commas and | symbol are essential, as they define what will be interpreted as a new vaccine or separate piece of information by JavaScript. Using this format, I do not need to have separate parameters on my Solidity functions and can save on gas costs by separating the data appropriately in JS.

The string input of registerData

Step 3: Website

Now that sorting through the data has been dealt with, I need a way to display it. The goal is to have a way to easily access this data from anywhere, so I opted for a (mobile responsive) website. This is what it looks like:

Desktop and mobile versions of the website

For now, to host it, I used a free hosting service and free domain name. The website gets the updated data from the blockchain anytime it loads, and, it is worth noting that this comes at no cost, with no need for a transaction. Getting the data is a simple call of a view function.

Thus, my costs (USD) for registering all my vaccines immutably on the blockchain and creating a website to display them anywhere were:

  • Contract publishing cost: $0.28
  • Function call cost: $0.53
  • Total cost: $0.81

Further (technical) considerations

Skip this section if you do not care about the technical aspects from behind the scenes. Here I will give some more detail regarding how I built this application and what tools I used.

Firstly, I want to encourage developers to begin creating similar useful solutions. The dApp I describe in this article cost me less than $1 to create, has a clear value to me and was built in about a day with less than 300 lines of code. The most difficult part of building this was deciphering what was written in my Brazilian vaccination card.

As previously mentioned, I want to once more note that I could implement further features, both in the smart contract and the front-end. I could, for example, have a front-end that allows me to select what vaccines to display, or see all vaccines in a given year. However, as for now, my decision was to keep this as simple as possible, making the argument that there is value in simplicity. However, those features could be implemented in the future.

As for the development process, I began by writing the smart contract and testing it locally using Truffle and Ganache. After doing so, I built the website and deployed it locally, still using Ganache, but testing that the interaction between the smart contract and front-end was executed properly. This was done using the web3.js library. I then moved my testing to the Ropsten network, and used MyEtherWallet to interact with the contract. I did not create a way to call registerData from the website itself. After testing on Ropsten, I then finally deployed it on the Mainnet, and used free hosting to get the website live. For Ropsten and the Mainnet, I used an Infura endpoint as a fallback mechanism if MetaMask is not present. As such, users (i.e. me) do not need to use a dApp explorer to see the data on their phone, for example.

The JavaScript code runs as soon as the page loads and calls a function to check the length of the vaccines array. It then calls the getData function enough times to gather all the data registered (currently that means calling it one time) and concatenates it. It then iterates through the data, separating the vaccines from each other. Then, it separates each of the pieces of information for each vaccine registration and adds them to their respective cells on the table.

Lastly, for the front-end, I used Bootstrap in order to have a smooth-looking table, but did not mess with colours or design. Oh, and all the HTML, CSS and JS are in the same file, sorry.

The smart contract and website amount to 289 lines of code in total, and it can all be found here.

Conclusions

The main point I want to get across with this article is about how easy it is to build applications for Ethereum that actually add value to our processes.

It is easy to get caught up with a big vision and aim to change the world, but by focusing on small, useable solutions, we can actually begin to create value and drive adoption of the technology. Also, for developers, another point I would like to emphasise is the importance of proper design, which is important not only for security reasons, but can also help in lowering your expenditure for projects.

Finally, as you can see, the total cost of creating this dApp, publishing it to Ethereum’s main network and using it came to a total of $0.81. This is an application that I will truly use and that will help me in the future, and I don’t have to worry about maintenance or records being deleted. It’s immutable and it’s available, anytime, anywhere.

So, what is it that you want to build to make your life easier?

-

P.S. If you’re looking for blockchain events to attend, tickets have now been released for LBL’s BIDE Conference. More info here.