Applying blockchain to healthcare - part 4 (storing data)

In my previous blog post, I talked about how blockchain is a database that can be trusted.  In this post, I want to show how we can store data in blockchain using ethereum - a popular open source project which is based on blockchain.

Storage in ethereum is handle by smart contracts.  A smart contract instance consists of the following:
1) Data - named properties with different types such as strings, numbers, arrays, bytes and maps.  The data is highly structured like a SQL Schema (not like unstructured NoSQL databases)

2) Code - functions that can receive parameters, return data and access data in the smart contract.  The code is tightly coupled to the data similar to how methods work in object oriented languages facilitating encapsulation.  SQL Stored procedures are also similar but are procedural rather than object oriented.

3) Address - a globally unique address which allows access to a specific smart contract.  This is similar to a pointer or reference to an instance in an object oriented language, or a document identifier in NoSQL or a row id/primary key in a SQL database.

Smart Contracts are not organized like rows are in SQL tables or documents are in MongoDB collections.  Smart contracts simply exist in ethereum and have a unique address.  This is similar to how you instantiate an object or struct in memory with most languages (except they are persistent in ethereum).  Smart contracts are similar in concept to a persistent distributed object that was popular in the 90's with DCOM and CORBA technologies.

Lets assume we are building a healthcare application and want to store patient demographics (a very common feature).  In SQL, we might have a Patients table with columns defined for primary key, name, date of birth and gender:

CREATE TABLE PATIENTS (
   ID      INT,
   NAME    VARCHAR(64),
   DOB     DATETIME,
   GENDER  CHAR(1),
   PRIMARY KEY( ID )
);

In NoSQL, we might store a JSON document that has properties for document id, name, date of birth and gender:

{
  id: "a0e430cc-e386-473a-a81f-310f0f733f47",
  name : "DOE^JOHN",
  dob: new Date("FEB 1, 1973");
  gender: "M"
}

In ethereum, we declare a smart contract with data members for name, dates of birth and gender as well as functions that are used to set or get those data members:

pragma solidity ^0.4.2;

contract Patient {

  string public name;
  string public dateOfBirth;
  string public gender;

  // FAMILY^GIVEN^MIDDLE
  function SetName(string _name) {
    name = _name;
  }
  // YYYYMMDD 
  function SetDateOfBirth(string _dateOfBirth) {
    dateOfBirth = _dateOfBirth;
  }
  // M,F,U,O
  function SetGender(string _gender) {
    gender = _gender;
  }
}

The above smart contract can be compiled using Remix, the solidity online compiler.  Once compiled, you can deploy it into an ethereum deployment (e.g. main net, test net, testrpc, or private network).  For the purpose of this blog, we will run a ethereum virtual machine simulator in the web browser so we don't have to deal with accounts, ether and deployment.  Click the "Environment" icon in the upper right (looks like a cube) and select the first radio button "JavaScript VM".  Now paste the smart contract above into the editor in the IDE.  Remix should automatically compile the smart contract and show a red "Create" button.  Click the red "Create" button and an instance of our patient smart contract will be created.  At this point, remix has created an instance of the smart contract and returned its address.  

You will notice blue buttons for each data member that can be pressed to show the value of that data member.  Initially they are empty, but we can easily set them by entering strings in the edit boxes next the red buttons and pressing the red buttons.  Lets do that now - enter the string "DOE^JOHN" in string_name and press the button "SetName".  Remix responds with some data and we can now check to see if the data got in there by pressing the blue "name" button.  Press it now and notice the "decoded" value shows "DOE^JOHN".

Congratulations!  You have now created your own patient smart contract and deployed it.  This smart contract could be used to represent a single patient in your application. Next post we will look at adding validation logic to the smart contract.