Applying blockchain to healthcare - part 9 (access control)

In my last blog post, we explored how ethereum accounts and digital signatures are used to implement a new form of identity and trust.  In a prior blog post, we used the following Patient smart contract:

pragma solidity ^0.4.2;

contract Patient {

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

  // Event that is fired when patient is changed
  event PatientChanged(string what);

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

While this smart contract allows anyone to access the data, it also allows anyone to modify it.  Once this smart contract is published, anyone can see the patient's name, date of birth and gender.  Anyone can also change these properties.  Cleary this does not meet the need for privacy or control.  While access is a major privacy concern - it isn't something we will explore in this post (but will in the future).  In this blog post, we will be exploring how to implement access control on modifications to smart contract instances.  We will do this by using a new smart contract named PatientAllergies which manages a list of allergies for a patient.  Access to allergies is an important part of patient safety as giving a patient a medication they have an allergy to can kill them.  Here is the PatientAllergies smart contract:

pragma solidity ^0.4.2;

contract PatientAllergies {
    // the address of the owner (the patient)
    address public owner;
    // address of physician that can add allergies
    address public physician;
    // name of the patient LAST^FIRST
    string public name;
    // array of allergies this patient has  
    string[] public allergies;

    // constructor that sets the owner to the address creating
    // this smart contract
    function PatientAllergies() {
        owner = msg.sender;
    }

    // allows owner to change the patient name
    function SetName(string _name) {
        // only allow the owner to change the patient name
        if(msg.sender != owner) {
            throw;
        }
        name = _name;
    }

    // allows physician to add an allergy
    function AddAllergy(string _allergie) {
        if(msg.sender != physician) {
            throw;
        }
        allergies.push(_allergie);
    }
  
    // allows owner to set the physician that can add allergies
    function SetPhysician(address _physician) {
        if(msg.sender != owner) {
            throw;
        }
        physician = _physician;
    }
}

You may recall that an ethereum transaction includes a digital signature that ethereum uses to make sure that the account that created the transaction is who they say they are.  The transaction therefore includes the account information and is exposed to smart contracts via the msg.sender property.  msg represents the message (or transaction) being send to the smart contract.  msg.sender is the address of the account that sent it.  We can implement access control by checking msg.sender in functions to see if the caller (user) is able to perform specific operations.  In this case, we assume the account that created the smart contract is the patient and store it in the owner property.  Once this is done, we can add an access control check in the SetName() function so only the owner (patient) can change his name.  We also add a function SetPhysician() that the owner (patient) can invoke to set the address of a physician who is trusted to update the list of allergies.  The AddAllergy() function checks that the account trying to modify the list of allergies is in fact the address the owner(patient) has allowed.

What does this example mean to healthcare?

For patients, it means they can manage their medical record online and control who can make changes to them.  In this case, the patient is the only person who can change the patient name.  The physician that the patient chooses is the only person who can add to the allergy list.

For physicians, it means they can obtain access to the patients list of allergies by interacting directly with the patient.  The patient just needs to give the physician the address of the smart contract and the physician can see the allergies.  The physician does not have to wait until his EMR is integrated with some other EMR, the hospital is connected to an HIE or IT has the right VPN in place.  Trust and access is managed directly between the patient and the physician.

Please keep in mind that this example is overly simplified to illustrate how access control can be implemented with blockchain.  A real application would be much more complex allowing multiple physicians to manipulate the allergy list, the ability to revoke physicians from the access control list and provisions of changing the owner in case the owners private key is compromised.

Next up is how to protect private keys with wallets

Applying blockchain to healthcare - part 8 (accounts)

Ethereum utilizes public key cryptography to secure the blockchain.  Public key cryptography uses a pair of keys: a private key which is kept secret (like a password) and a public key which can be shared with anyone.  A private key is created using a random number generator and the public key is generated from an algorithm that takes the private key as input.  The algorithm only works one way - the public key can always be derived from the private key, but the private key cannot be derived from the public key.  Ethereum takes this cryptographic key pair one step further by generating an Ethereum address from the public key.  This algorithm is also one way - an address can be derived from the public key, but not vice versa.

The ethereum network only knows about addresses - it does not store private keys or public keys.  When a user wants to make a change to the ethereum network, it creates a transaction.  Each transaction must be paid for using ether - the currency of the ethereum network.  Each ethereum account has an associated balance of ether that is used to pay for transactions.  To ensure that the private key associated with the account paying for the transaction has authorized the transaction, each transaction includes a digital signature produced by the  elliptic curve digital signatures algorithm (ECDSA).  Ethereum checks the digital signature and will not process transactions unless they are valid.

In the prior blog post, you may recall metamask prompting you to confirm a transaction:



Metamask is a browser extension that provides secure and user friendly management of ethereum security.  Metamask lets you as a user create ethereum accounts and presents confirmation dialogs for you to approve spending any of your ether.  In the example above, the name I gave this ethereum account "Coinbase (local)" which corresponds to an account in my ethereum private network.  You will also see some of the characters of the ethereum account - "5DEFE02...2fcc".  Next you will notice the ether balance of the associated account - in this case "216675.000" ETH and the value in USD "4191279.82 USD".  You will also notice it telling you that it is creating a new contract "New Contract" and the maximum amount of ether it will cost to execute the transaction "0.094000 ETH".  Given that the EVM which runs smart contracts it Turing complete, it is not possible to determine the cost of a transaction ahead of time so an upper bound is specified when creating the transaction.  After the transaction is executed, the actual cost is dedicated from the account.

Ethereum's approach to security is important to understand as it is the foundation of how identity and trust is managed which is what everyone is so excited about.  Ethereum's private keys provide a universal way for end users to be identified.  Digital signatures provide a way for ethereum to verify identities.  This is actually quite profound as it allows end users to interact directly with the ethereum blockchain without having to trust any intermediaries.  This is completely different than almost every application we work with today.  Today, we have to prove who we are to the applications usually by logging in using a password.  This works great, but requires that we fully trust the application we are logging into.  In the case of ethereum, there is no application layer to trust.  We as end users can directly assert who we are and what we want changed in the blockchain and no intermediate application layer is required. An end user therefore has full control over any data they put on the blockchain and no human, government or corporation can change it.

What does this mean for healthcare?

It means a patient can put their medical records on the blockchain and control it directly.  They can choose who can see it and who can't.  They can choose who can add to it, and who cannot.  It eliminates the need for patients to trust applications (such as patient portals), the administrators of those applications (system admins), or the corporations (hospitals) that control their data.

It means a physician can obtain access to a patient's medical records by interacting directly with that patient.  The layers of security currently in place are not needed.  Hospitals would not have to have connections with an HIE or other hospitals.  The EMRs from different hospitals do not need to interoperate.  IT does not need to be involve.d  The physician would be able to directly access the information they need, all it requires is the patient to approve it.

Suppose a patient is on vacation and suddenly faints.  The patient is admitted to the local hospital emergency department and since the hospital has no record of this patient, has no knowledge of this patients medical history.  The patient might be able to provide some of his medical history verbally - but how accurate is it?  The hospital can try to obtain the medical records from the patient's hometown hospital - but can it be obtained fast enough and can it be imported into the local hospitals information systems?  Storing medical records on the blockchain can solve these issues and it all begins with identity.  End users simply need ethereum accounts and access to the public blockchain.

Next up is using ethereum accounts to implement access control on the patient record.

Applying blockchain to healthcare - part 7 (filters)

In my last post, I showed how events could be added to the Patient smart contract so external systems can be notified when it has changed.  In this post I will show how these events can be detected from a web browser application using filters and then use them to look at how the state of the patient smart contract changed over time.  As previously mentioned, blockchain is immutable and update operations work differently than they do in normal databases.  Rather than overwriting the old value with the new one, ethereum records the change and keeps the old value around.  When interacting with a smart contract instance, the default behavior is to use the most recent state.  It is possible though to access historical state - much the same way you can access older versions of a file with a revision control system.  You can find the source code for this application here,  including instructions on how to run it on your local machine (if you have a Mac that is).

After starting the application, you are given the choice to create a new patient smart contract instance or attach to an existing one (assuming you know its address):



In this case, we don't have an existing instance so press "Create" to create a new one.  Metamask will prompt you to confirm the transaction - press "Accept" to do so:



After several seconds, the newly created patient smart contract instance will be created and stored in your private ethereum network.  The address for this newly created instance is displayed in the UI and controls appear to modify the properties of the patient smart contract:


At this point, you can set the values for the patient's name, dob and gender by entering the strings and pressing the corresponding "save" button.  Metamask will prompt you to confirm the transaction every time you press save.  After waiting a few seconds, you can hit the "Refresh" button to see the history of changes to this patient:



The change log shows a few things - the block number that contains the change, the timestamp of the block, the type of change and the values for name, dob and gender at that time point.  Recall that a blockchain is a series of blocks each of which has a pointer to the prior block thus creating a chain.  The blocks store transactions will cause changes to the state of the blockchain.

As stated before, the blockchain is immutable so all prior states are always accessible.  Changing the name from "DOE^JOHN" to "SMITH^WILLIAM" results in a new block being added with this change, but does not go back and modify prior blocks as the blockchain is immutable:



Immutability is an important concept of blockchain that has some interesting implications.  It means that records cannot ever be tampered with.  There is no human, corporation or government that can go remove or alter information on the blockchain.  Once data is added to the blockchain, it will be there forever!  In healthcare, there are few (if any) use cases for destructive changes to data.  This makes blockchain an excellent fit for storing medical records.  Most healthcare applications today have poor (if any) support for accessing historical changes to medical records.  With blockchain, keeping track of changes is automatic and doesn't require any special coding by developers.

You should now have a better understanding of immutability, how it applies to healthcare.  You should also have a better understanding of the ethereum event and filter mechanisms.  Next up is exploring the concept of identity management and trust with blockchain.

Applying blockchain to healthcare - part 6 (events)

In my last post, I added validation logic to the Patient smart contract.  In this post, I want to add an event that is fired every time the Patient smart contract instance is changed.  Events are useful for two main things - notifying systems external to ethereum about changes in ethereum and for simple querying.  In this blog post we will focus on using events for communicating with systems external to ethereum about changes to the Patient smart contract instance.  This could be used to update the UI automatically or to keep an external database in sync with the data stored in ethereum.  Keeping a database in sync is a common use case since ethereum has limited query support.

Here is the Patient smart contract with an event "PatientChanged" that is fired every time the patient smart contract instance is changed:

pragma solidity ^0.4.2;

contract Patient {

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

  // Event that is fired when patient is changed
  event PatientChanged(string what);

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

Note that I removed the validation logic added from the last post as it is not necessary to discuss events.  In this case, the property that caused the change is included with the event.  You can see this in action by pasting the above smart contract into Remix and changing a property:

In the screen shot you will notice that the event PatientChanged is logged with the value "name" listed.  You can try changing the other properties and you will see the event fired with what being either dateOfBirth or gender.  External systems can create a filter to listen to various types of events.  Filters take as input "topics" which can include any of the following:
1) Address of a smart contract - will return all events related to the smart contract at the specified address
2) Event type - will return all events of a specific type (e.g. all PatientChanged events for all Patient smart contracts)
3) Event data - will return all events that have a specific data item. NOTE: This is not done in the example above.

Next up is setting up a filter to detect modifications to the patient smart contract instance and inspecting the past state of the patient object (remember that blockchain is immutable and all prior state is accessible forever)

Applying blockchain to healthcare - part 5 (logic)

In my last post, I showed how to store data in a blockchain using an ethereum smart contract.  In this blog post, I will expand on that and show how to add validation logic to the smart contract.  Here is the Patient smart contract updated with logic to enforce a little bit of validation logic:

pragma solidity ^0.4.2;

contract Patient {

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

  // FAMILY^GIVEN^MIDDLE
  function SetName(string _name) {
    if(bytes(_name).length <= 0) {
        throw;
    }
    name = _name;
  }
  // YYYYMMDD 
  function SetDateOfBirth(string _dateOfBirth) {
    var dobBytes = bytes(_dateOfBirth);
    // check length
    if(dobBytes.length != 8) {
        throw;
    }
    // check for numeric
    for(var i=0; i < 8; i++) {
        if(dobBytes[i] < '0' || dobBytes[i] > '9') {
            throw;
        }
    }
    // validate year, month, day
    dateOfBirth = _dateOfBirth;
  }
  // M,F,U,O
  function SetGender(string _gender) {
    var genderBytes = bytes(_gender);
    if(genderBytes.length != 1) {
        throw;
    }
    if(genderBytes[0] != 'M' &&
       genderBytes[0] != 'F' &&
       genderBytes[0] != 'O' &&
       genderBytes[0] != 'U') {
           throw;
    }
    
    gender = _gender;
  }
}

The logic should be easy to understand for those with programming skills.  A few notes about this:

1) In each case, the string must be cast into bytes to perform validation.  Solidity unfortunately has poor support for strings - you cannot check individual characters or even the length!  The solidity-stringutils library provides much needed string functions.  

2) Solidity currently has very limited support for exceptions - you cannot give them a name or add any data to them.  To the caller, an exception is returned with a cryptic error like "VM Exception: invalid JUMP at 034277a5bb8a98c36ad8ebf8d38277272ce38b35e6a39916f77bd6c3903e8c45/692a70d2e424a56d2c6c27aa97d1a86395877b3a:2119"

Hopefully this gives you an idea of how data can be stored in ethereum and logic applied to that data. Next up is looking at ethereum events which allows enables notification of changes in ethereum to the outside world and basic queries.

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.

Applying blockchain to healthcare - part 3 (a different kind of database)

If I was to describe what blockchain is in one sentence it would be this:

"A distributed database that can be trusted"

Lets break this down a bit:

"A distributed database"

A database that runs on many computers, each of which has a full copy of the database and work together to keep things in sync.  This is similar to a high availability database deployment like you might see with SQL Server, Oracle or MongoDB - with a few significant differences:

- Number of computers.  A SQL Server HA deployment typically consists of two computers - an active node and a passive node.  A blockchain database has no real limit on number of computers and some deployments run on thousands of computers (e.g bitcoin, ethereum).

- Connectivity between computers.  A SQL Server HA deployment requires a reliable connection between the active and passive nodes.  If the network is not reliable, the system will run into many problems trying to figure out who is in charge.  This often results in the deployment of the computers being in the same data center.  If the active and passive are split into separate datacenter, there must be a high speed and reliable network between them.  Blockchain on the other hand assumes the network is not reliable.  Any given blockchain node can come and go at any point and the entire system will continue to function.  The network can even slow down and the system will continue to function.

One of the benefits of blockchain running on multiple computers and being resilient to network problems is that it is much more reliable.  Computer and network failures happen regularly on blockchain, yet the system continues to run - thus giving us confidence that it will not go down.  Contrast that with a HA SQL Server deployment.  A failure on such a system is very rare and you often discover it isn't working as expected until a failure actually occurs.

"database that can be trusted"

Blockchain brings a different model of trust than we are used to and this is probably the hardest thing to fully understand as it requires a paradigm shift.  Today we put our trust in many things that are not in our control.  We trust the bank with our money, we trust the government to represent the peoples interests, the media with truthful reporting and even our IT administrator with our data.  Is SQL Server trustworthy?  In some ways it is - it is proven technology and as a developer, I am very confident that doing an INSERT or UPDATE will work properly.  I even trust that its authorization and authentication mechanisms work to protect sensitive data.  While this sounds like a trustworthy technology, it has several shortcomings:

- Identity management handled by applications.  Databases typically have user accounts, but they are rarely integrated with end user accounts.  Database accounts are typically granted for applications that handle identity management for end users.  The application may delegate authentication to a centralized system such as active directory, but once the user is authenticated, all database actions are done on behalf of the applications database account.  What this means is that end users have to trust the application to do the right thing as well as everyone who has higher levels of access.  This is rarely a problem in the real world as those with higher levels of access are trustworthy - but this is not a guarantee.  It is entirely possible for someone with higher level access to do bad things.  For example, an IT administrator could delete records from a database that recorded actions by staff that resulted in the death of a patient to avoid potential fines from a malpractice law suit.  I hate to say it, but chances are this has happened and likely more than once.  With blockchain, changes are validated via a digital signature signed by the end user.  Identity management is handled by the end user, not the database!  The database simply validates that actions done by a user are in fact done by that user and nobody else.  It is impossible for anyone but that user to impersonate them (assuming the private key is kept secret).  Decentralizing identity management gives us as users a level of trust that we don't have today with existing database technologies.

- Data is immutable.  This is a new aspect to databases for most of us - it means that once a record is written, it can never be changed.  This means UPDATE and DELETE actions don't work the same way.  An update to data is done by writing a new block to the blockchain saying it updated the data - the original data is never changed (it is left in the blockchain).  Data immutability gives us a level of trust with the underlying data that we currently don't have.

Data immutability with decentralized identity management provides a new paradigm of trust.  It means that end users can be fully in control of their identity and the changes made on its behalf.  It also means that we have a full history of data changes that cannot be changed or corrupted by anyone.  While these properties increase end users control over their data, it also puts a higher level of responsibility on them - specifically around managing their private keys.  Fortunately there are hardware wallet solutions available today such as trezor, ledger and uPort (via iOS/Android devices) to help with protecting private keys.

Blockchain Drawbacks

This may sound great, but the blockchain database has a few drawbacks compared to SQL and NoSQL technologies:
1) Blockchain has a much lower transaction throughput.  While A SQL or NoSQL database can support transaction times in milliseconds, blockchain often operates in seconds, minutes or even hours!  The slowness of blockchain transactions means we can't use it as a direct replacement for the databases we use today.
2) Limited or no query support.  Blockchains are more of a write only transaction log than a database.  For most solutions, a SQL or NoSQL database is populated with data read from the blockchain so query operations can be performed against it.  In the case of ethereum, filters can be used to do primitive queries.  Some query use cases can be addressed by processing the queries in a smart contract or perhaps in the application tier.
3) Cost.  Blockchain requires considerably more CPU, storage and network resources that a corresponding SQL Server HA installation.