The library catalog is a relic of days gone by, but in its prime, it was the best way to find what you were looking for at the library. The Dewey Decimal System (DDS) was a simple, yet specific classification system. A book gets an identification number based on its subject, author, title, and version. The number indicates its location on the shelf. To find the book, you’d go to the catalog and look up its card. If the card wasn’t in the catalog, the book wasn’t available. Simple.
This is what managing medical data on a blockchain looks like.
The blockchain is the catalog, and medical records are the books that it references. It can perform the basic functions of a registry and a resource lookup. A blockchain becomes a network when we connect identities and applications.
It keeps a permanent log of all interactions and replicates it across every connection point on the network. It can guarantee that the item you’re looking for hasn’t been forged, duplicated, or tampered with.
The blockchain can store access permission lists and other application data, which allow us to authorize access to information based on credentials. If your credentials don’t have permission, then it’s as if there’s no card in the catalog–the record is not available.
A blockchain is like a library catalog that can point you to any book in any library, anywhere in the world with guaranteed integrity, but only if you have permission to check it out.
The library catalog is a simple registry of resources stored throughout the library. It doesn’t do much more than that. A blockchain is similar in that regard, because it is simply a log of events running over a relay network. It doesn’t do very much either.
It does take instructions however, which means it supports applications. These applications are what make blockchains such a powerful utility.
At Gem, we build and support these applications using GemOS, our blockchain “operating system.” This system connects data stores, networks, and identity registries to an application platform that uses the blockchain as the common data repository. Applications to build layers of logic and security on top of it that can be customized to the specific needs of a business.
Like the library catalog, the blockchain itself is fairly basic in form and function. It only records the data we put into it.
Unique Identifiers for Medical Data
The DDS classifies more than just books. It classifies all types of resources including papers, journals, magazines, articles, and notes. A blockchain does this as well. On-boarding documentation, prescriptions, patient interactions, and payment requests are all examples of the types of “events” we can register on a blockchain.
Similar to the Dewey Decimal Number, everything that is registered on the blockchain is assigned a unique ID number, called a “hash.” The hash is not a randomly generated number; it is unique to the content of the event file.
For example, a study was performed on Julian by Dr. Madeline on July 5, 2016. This is a unique event, so Dr. Madeline’s report will have unique information about the doctor-patient interaction.
In the blockchain application, we use a cryptographic algorithm to create a hash based on this specific data. Every time we apply the algorithm to this document it will produce the same hash. If any data changes, the algorithm will produce a different hash. The hash of a file cannot be used to recreate the content of that file. So if this number is exposed to an unauthorized party, the information it represents is still a secret.
A Dewey Decimal Number cannot tell you if a book is damaged or altered, but a hash can.
Because the hash is unique to the file’s contents, it can guarantee the integrity of the file. When we record the hash of Dr. Madeline’s report, we enable future users to verify that the contents of the report have not been modified. If the document has been modified, it will produce a different hash, and the values will not match.
The hash is not only an identifier; it’s an integrity check.
Data Access Management
When we record an event on the blockchain, not only does it include the hash but also access permission lists. These lists are stored on the blockchain with the hash, and they act as instructions for the blockchain applications. They tell the application if the user has access rights to the document.
Patients, doctors, nurses, or anyone really can control access to data by storing user permissions on the blockchain. The hash, along with the user identifiers and permissions, is recorded in a single event on the blockchain. Now, when applications search for that file using the hash, they read the user permissions, check it against the credentials of the end-user, and authorize access to that information.
So, when Dr. Madeline registers Julian’s visit report on the blockchain, she gives him permission to add and remove other doctors. When he visits Dr. Duong, a rheumatologist, he adds a new viewer to that record. When Dr. Duong searches the blockchain for the record, the application will confirm his credentials and authorize access.
A Collaborative Version Control
Managing health data between multiple providers is messy. Today, each party maintains their own copy of the health record, making changes and updates to it that no one else can see. Then they each devote an enormous amount of resources to reconciling all the different versions of that health record.
Blockchains eliminate data reconciliation. Instead of each party maintaining their own locally stored version of the truth, there is one record registered to the blockchain that owner shares access to.
Once a file’s hash is recorded to the blockchain, the contents of that file cannot be changed. So, when we want to update or append that record, we must create a new record on the blockchain that references the original. (Note: This file-directory structure is designed at the application layer and does not fundamentally change how the blockchain logs interactions.)
When Julian visits Dr. Duong, this is a new episode of care with a different doctor on a different IT system. Just like Dr. Madeline, Dr. Duong records this visit report to the blockchain. He also orders labs, creating a new event on the blockchain.
Dr. Duong gives “editing” permissions to the laboratory, allowing them to update the order with the lab results. When the lab results are added, they are attached to the order as a new version. Either document’s hash number will deliver the most recent version of the file. We can program the application to notify Dr. Duong when the lab results are registered, and he can view them immediately.
In this example, we have two collaborators on the same medical record (three if you include Julian). Any interaction with the record is recorded to the blockchain, so we always have a record of who added what changes, when.
This is how we can use the blockchain as a version control when managing medical records between multiple providers.
At its very core, a blockchain is a ledger. The blockchain is a log of every single interaction, including when a record is created, accessed, appended and shared. Every interaction is recorded as a unique event and is given a time-stamp and a hash. Attaching hashes together sequentially creates a permanent chain of events. This is where the word “blockchain” comes from.
One very important feature of blockchain technology is that the full ledger is replicated across every connection point — or node — in the network. This means that the complete registry and its user activity is shared by all the participants. If one node goes down, the network stays on.
Because the ledger is replicated everywhere, it becomes tamper-proof. If a bad actor tried to change a historical event, the hash would change, and it would break all the subsequent events in the chain. Every node has a living copy of the blockchain and would identify this as an attempt to break the network. The change would be rejected.
This highly-redundant, tamper-proof ledger becomes the irrefutable audit log for the entire network. This matters because blockchains are a shared utility that can connect non-trusting parties, and those parties need guarantees that their data cannot be tampered with by other actors.
When combined with strong identity, the ledger becomes the ultimate indicator of who did what, when on a blockchain. It is the basis of truth for every interaction that every party can agree on.
Rather than trusting a single authority, the librarian, to maintain the ledger, the users can trust the catalog itself.