Blockchain
This week’s topic
Blockchain. More specifically, this will kick off our series of articles on blockchain technology and how it can be used for digital health apps.
Background information
Blockchain is a very hot topic these days and many people might wonder what the fuss is all about. There are innumerable books on blockchain and analogies to the technology abound.
A blockchain is an ordered list of transactions. It is not a store of current state but the current state can be calculated by iterating over the complete set of ordered transactions.
For people with a more technical background, blockchain can be thought of as a singly linked list, that is meant to be traversed backwards. Each object in the list (block) has a reference to the previous block.
For people with a less technical background, blockchain can be thought of as a book, where the pages are not numbered or bound together. Instead, each page (block) has a reference to the page (block) that comes before it.
How blockchain differs from a database
Blockchain differs from a database both in the storage system itself but, more fundamentally, in the type of data typically stored and in the architecture of the system itself.
In a database, say you want to run a query to find out the number of patients for all providers in your system. This query will identify the number of patients per provider currently – right now. That is very easy to model in a relational database. For example, let’s assume we have the following records in our database:
As you can see from the tables above, we have a provider / patient table that links providers to their patients. The table contains a date which records when the patient selected the provider. Right now, for our provider John Doe, there are 2 patients and for our provider Jane Doe there are 4 patients.
One question is: what do we do when a patient selects a different provider? We could simply change the provider / patient link to reflect the change, which would accurately reflect the current state.
However, we often want to keep records of prior states – not just the current state. We could do this with the data model above by adding an “is_current” column to the provider / patient link table. Then, whenever a patient selected a new provider:
- The linkage record for their previous provider would have its “is_current” flag cleared
- A new linkage record would be added, with its “is_current” flag set to Y
Effectively, the provider / patient link table is saving two types of data: current data as well as transactional data. The ability to see “current” data and prior data can be accomplished in many ways in a relational database or a data warehouse.
The biggest difference between blockchain and a database is down to the system architecture. A database or data warehouse is, by definition, part of a client/server architecture. It is a central data store that the whole system interacts with. However, a blockchain enables peer-to-peer distributed application architectures. Using a blockchain for storing data can eliminate the need for centralized storage as part of an application. Each peer or node can save the full blockchain, which is a record of all transactions.