Demystifying Blockchain In 8 Days: Part 2
This article covers the second part of our final project at Makers. The first part covered what a blockchain is, and how we created a proof of concept blockchain. If you haven’t read the first article, you can read it here.
In this article I will discuss how we integrated the blockchain algorithm into a full-stack web application. I’m going to discuss how the app can be used to provide a secure history of patient prescriptions.
We first planned how the app would fit into a health system. From there we created three user types who would engage with the app on different levels.
I’ll then go into the structure and data flow of the app from the perspective of one of the users. The reason I only cover one user type is because the different users share a lot of similar features so covering all of them would be repetitive. Finally, I’ll discuss improvements & additional features for future iterations.
Homer Visits The Doctor
To understand how people would use the app in the real world, we had to think about how people order prescriptions.
Let’s say Homer Simpson starts developing back-pain. His back pain could be caused by anything. So he goes to see a specialist, Doctor Hibbert, to understand the causes of his back pain & develop a strategy to alleviate the causes and symptoms.
Doctor Hibbert prescribes Homer Simpson some anti-inflammatory medication and recommends he makes some lifestyle changes. He tells Homer Simpson about the prescription and adds it to the patient prescription system.
Homer then goes to the pharmacy, where the pharmacist has access to all the patient prescriptions. Within 5 minutes, he has paid for his prescription. He returns home, takes his prescription and begins his new exercise routine.
The Users Of The System
The above story offers a snapshot of the different user types in a prescription system and their responsibilities.
- The doctor adds prescriptions to the system
- The pharmacist has the ability to review all the prescriptions
- The patient can access their personal prescription information
These users don’t care (and nor should they) about the technology that powers the system; all they need to care about is that it works and offers a secure and reliable environment for managing prescriptions.
Once we understood the three basic user types, we developed user stories for the app. The three main user stories we came up, which summarise Homer’s (and the majority of people’s experience) are:
- As a Doctor so I can improve the health of my patients, I want to be able to view all prescriptions, and add prescriptions to the system.
- As a Pharmacist so I can quickly retrieve the correct prescriptions, I want to be able to view all patient prescriptions.
- As a Patient so I can keep track of my medication, I want to be able to view only my prescriptions
Developing The Doctor’s Features
The first thing we did was break down these user stories into smaller chunks and worked out what they had in common. The most important similarity they shared was the need to log in and out of the system. The different levels of authorisation could be set at log-in.
For this feature the app needed a public interface, a controller for checking login validity and a database to stored the logged in users.
We decided to use a model-view-controller (MVC) architecture to manage the user-interface and created different routes (or web urls) that each user type would visit to login to the app. The model is used to manage connections to the database and the views manage the public interface of the app (what the user sees). The controller acts as an API. It validates data from the user and then sends the data to the model.
Through the controller all the routes/web-urls are defined to represent the different state of the app (successful login/failed login, added prescription ect).
Once the user visits the app they are directed to the login page, where the three different user types are present.
Let’s say I’m a Doctor and I want to register. I click on the registration button and get directed to the doctor registration route. Behind the scenes the doctor registration controller is managing all the login and registration behaviour.
I then fill in the correct information and the app then visits the post request route. Post requests are used to manage any private information regarding users.
Here two things can happen.
- The user enters invalid registration information or tries to register with an existing user.
- The new doctor is successfully registered and logged in
The registration information is checked by two simple functions that ensure that every form entry is filled in, and that the two passwords are equal. The second step is slightly more complicated.
The log in new doctor function is invoked. Prior to logging in the doctor the database of all doctor registrations is searched. If any doctors match the current registration information then an error is logged.
If the registration is successful then the doctors registration information is saved to the database. The database schema, or structure for organising the registration data is managed through the model file.
Each entry from the form is applied to the document that will be saved in the database. The entries are checked for uniqueness. Using the bcrypt encryption library, the passwords are then encrypted before the information is saved in the database. Encryption is used to ensure that if the security of the database or app is compromised the users passwords remain hidden (unless the hackers have access to the encryption key).
After the data has been encrypted we let the application know that a doctor has logged in through a session. A session is a piece of data that is stored on the server (back-end of the app the user doesn’t see) that persists across routes. That is, the data will not change if the user visits several URLs.
We use session data to reflect the fact that a doctor has logged into the application. Once a doctor has logged in, if a doctor chooses to visit another route (or another web page like BBC Sport) it does not matter. The state of a logged in doctor is saved throughout the app.
If a doctor is not logged in, and somebody tries to visit the add prescription page then they are redirected back to the home page (remember only doctors have permission to add prescriptions). This is because the add prescription route redirects back to the home page if there is no logged_in_doctor in the application.
Upon successful registration the doctor is directed to the add prescription page.
A very similar process is used for logging in an existing doctor. First the app ensures that every entry in the form is completed. The app then searches the database and identifies the doctor by username. The password associated with the user in the database is then decrypted. If the decrypted password matches the password entered in the form the session is invoked and user is directed to the add prescription page.
But What About The Blockchain?
The blockchain is not used to manage permissions or users. The role of the blockchain is only to store prescription data. The blockchain algorithm is thus only accessable via the add prescription functionality.
Upon initialising the app a blockchain is instantiated, and the controller also has access to the prescription and block creation objects.
The creation of prescriptions and blocks (which I explained in part 1) is invoked via the application routes.
If a doctor adds a prescription via the web form the application assigns the data to the prescription object via the prescriptions/confirmation POST request. The prescription object is then added to a new block, which is then passed into the blockchain.
Upon completion the app then directs the user to a page showing all the prescriptions. In the console, you can see the growth of the blockchain, and that each entry contains the encrypted hash of the previous entry.
What the doctor sees is an abstracted from the raw application data. They are only presented with the information they need to care about; the prescription data. The different users also only need to be concerned with the flow of data that is relevant to their needs.
As the app is web based it can be used on any computer that has a web browser. This would allow the app to be integrated into a health system like the NHS. It would not matter whether the hospital or pharmacy ran Windows, Mac or Linux. Provided the host had access to a web browser they can run the app. If this were a desktop experience you would need different versions for different operating systems, and maybe even different versions of operating systems!
Prescription fraud can also be checked, as if any existing entry is changed or modified then the validity of the system breaks down. Thus, the solution we developed offers an interesting prescription management solution that is both secure and relatively OS agnostic.
Concurrently from the developers perspective the app is structured around the different user types. This, combined with the unit and integration tests makes it easier to understand the code and add new features.
Improvements & Additional Features
So far I’ve shown how we integrated the prototypal blockchain into a web app. The product is far from finished so I’m going to quickly round off some of the things it would have been nice to have got done.
- Improved front-end (we can all agree colour scheme could be better).
- Finished functionality for patients and pharmacists.
- Web interface for prescription search algorithm we wrote.
- Web interface for blockchain validity checker we wrote.
The blockchain itself, being a proof of concept (and not an actual working blockchain) is currently stored in the session. To deploy the blockchain in the working world we would need some sort of database or distributed system to store the data. Using a linked-list structure for this makes sense, as new nodes can be added to the linked-list with the creation of each prescription.
Overall though it was a great experience. It showed how much gadiza zerari, Patryk Pilecki Sam Niechcial & myself learnt at Makers and how much you can get done in 8 days time by following good practices.
**If you want to check out the code in full detail, you can here**
