Zero to hero: My first blockchain development experience

June 26, 2020 | 8 min read

Lessons learnt and adventures from my very first blockchain development experience, developing a blockchain based healthcare application for BCA Finhacks 2019 competition.

At the end of 2019, me and my two friends took part in a blockchain innovation competition. Just like most competitions, we submit an idea to solve one of the real industry problems using blockchain technology. Turns out our idea was good enough for us to move to the next stage, creating a prototype. But here comes the twist, we had no prior experience of building anything related to blockchain. This post is my reflection on our idea, how we went from having no clue about blockchain development to successfully creating a prototype, presenting it to the judges, and achieving 3rd place in the competition. Enjoy!

me trying to reflect

Blockchain

Technological innovations are the product of problems and solutions. Humans encountered the problem of transporting heavy things, and hence invented wheels, as a solution to their problem. You’ve probably heard about blockchain, be it from the major 2018 bitcoin crash, or how startups started using the term “blockchain” as their pitch and selling points. A quick google (you’ll read this phrase a lot as we go) links to an article from Wired, which I think explains blockchain best in layman terms.

“Blockchain is all about storing and processing sensitive information — like financial transactions or voting records — on lots of different computers, rather than sticking it in all in one place.” — Wired


Understanding the problem

There are three main categories that are contested: Interbank Settlements and Payments, Identity Management, and Financial Inclusion. Our team chose to tackle identity management problems, focusing on Indonesia’s healthcare industry.

Around the time that the competition was held, one of my family members was hospitalized and we use Indonesian’s government insurance plan called BPJS to cover most of the medical fees. Over the months of being hands-on with the medical process in our current healthcare system and using BPJS, there are issues and potential issues that are quite apparent.

Scattered Records

Papers everywhere! I lost count on how many times I recheck documents every time we return from a hospital, or about to visit one. Medical checkup results, administrative receipts, insurance claims are printed on paper and are usually needed on hospital visits. As an engineer, I’ve always had the habit of thinking about the what-ifs. What if one single paper goes missing? What if someone (Bob) is in an emergency and brought to a nearby hospital, how do they access Bob’s medical history to make sure he receives the correct treatment?

Fraud

This will always be a controversial topic. In systems engineering, it’s always believed that no matter how perfect you think your system might be, there’s always a gap somewhere that is not thought of. In my opinion, this applies to every single system that exists in our world.

A deeper dive into these problems led us to several facts regarding medical negligence (errors in diagnosis, medicine prescriptions, or treatments) reported by the WHO and also fraud and overclaim problems in Indonesia’s government insurance business. Indonesia’s ministry of finance herself mentioned that BPJS will have a potential loss of 28 Trillion Rupiah by the end of 2019 as a result of fraud.

Po yelling wow!


Working out the solution

Our idea of solving the problem is by creating a blockchain-based application called SiBPJS, that will be run by the government and health providers to store medical records and insurance claims of patients, using BPJS registration as a method of identification. The platform will provide secure and accurate information regarding historical medical records, insurance claims, and other data with seamless authentication between health providers, insurance companies, and government.

Based on the explanation, we can now highlight the main features:

  1. Store documents (medical records, insurance claims) securely in the blockchain
  2. Authentication & authorization for document access

Lesson #1: Always be prepared for unexpected complexities when you’re learning something new, in this case, a new tech stack

Without taking into account the blockchain technology aspect, any engineer would probably say that it’s going to be quite simple to develop, just another CRUD application with additional authentication & authorization features (hell probably your college assignments were more complicated). That’s where we need to be careful. My habit has always been to create a proof-of-concept before committing to any timeline or features, just to get the grasp of development complexities.


First steps

It’s always important to kick off a project the right way. Thankfully, each team was assigned a mentor along with several mentoring sessions.

Lesson #2: Be honest and don’t be afraid to ask.

Having someone who understands the challenges that lie ahead of us is incredibly helpful. In our first mentoring session, we started by explaining how we have no prior experience in blockchain development. Don’t ever let your pride or fear of showing incompetence get in the way of learning. We shared a few laughs and then proceeded to have discussions about the competition, how to start developing, and what challenges that we’re expecting to face along the way.

My note from our very first mentoring session my note from our very first mentoring session


Progress

Warning! No pictures in this section. This is where I discuss most of the technical aspects and decisions for the application. Skip ahead if you don’t feel like heating up your brain 😂.

Public / Private Blockchain

This is the first question that we need to answer. A quick google links to an article from intheblack, explaining the differences between the two.

In a public blockchain, all transactions are public, and all nodes are equal. Bitcoin and Ethereum are well-known examples of public blockchains. A private blockchain is an invitation-only network. Entrants to the network require permission to read, write or audit the blockchain. There can be different levels of access and information can be encrypted to protect commercial confidentiality.

Through those definitions, it became apparent which blockchain structure we needed to choose based on our case. Since we’re dealing with private user records and a limited number of nodes (healthcare providers), private blockchain will be a great fit for us.

Smart Contracts

Smart contracts are lines of codes stored in a blockchain that will be executed when predetermined terms and conditions are met. By defining first what happens inside a smart contract, we can get the idea of how our blockchain application will work later. For our healthcare application, smart contracts are mostly used to securely store documents.

Consensus Algorithms

Consensus algorithms are decision-making processes for a group or blockchain nodes. It ensures that each block added to the network is the only true version and agreed by all the nodes in the network. There are lots of consensus algorithms out there, each with different tradeoffs and characteristics. Since our healthcare system is in a private blockchain and health providers act as trusted nodes, we used Proof-of-Authority consensus. With this algorithm, we don’t need to “mine” — which is basically solving complex mathematical problems, to reach a consensus for every transaction.

Scope of Application

Lesson #3: Know and understand the objectives.

Knowing the purpose of your application is crucial for the decisions you’ll make along the way. Basic questions such as who the users are, how many users, how will users interact with our app should be answered first. Part of my notes on the first mentoring session is dedicated to clarifying expectations about the prototype that we’re required to build. This ensures that we’re addressing the important features that will be graded first and leaving out the nice-to-have features to the later part of development. Since we’re developing this prototype for the scope of this competition and not for public use, our focus was to create a working application with basic features rather than creating a production-ready application following all the best practices (which we don’t really know yet anyway 😆).


Things that actually matter

SiBPJS' architecture

Fast forward to around a month after our first mentoring session, we created a working MVP that was presented to the judges. Using React as our frontend framework along with Ethereum for our private blockchain, our application was good enough to win us third place in the Identity Management category.

Picture of the top 3 teams for the identity management category. We're the ones on the left. Top 3 teams for the identity management category

I won’t deny that the thrill of winning is magical, but that’s not the moment that I remembered the most. I remembered when we first tried figuring out how to create a simple to-do app using blockchain. I remembered the sleepless nights integrating our front-end with the underlying blockchain. I remembered us practicing for our presentations after office hours. I remembered the late night last minute showcase preparation, creating quizzes, and buying gifts for people visiting our booth.

In the end, it’s about the journey, not the destination. It’s been a fun adventure learning and experimenting with blockchain technology. Special thanks to my teammates, Frieda and Robert with whom I embark on this journey.