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)