Distributed Ledgers, the next step in Patient Generated Health Data (PGHD) - Part II

An associate of mine provided good feedback on my previous post on Pulse,  he disagreed with me in earnest and stated that  Blockchain/ Distributed Ledger  (DL) wasn't a good platform for storing PGHD (Patient Generated Health Data).   I appreciated his comments, I decided to provide a bit more context and information.

For those of you that are not familiar with Distributive Ledgers, they are the technology that support Blockchain, which is the foundation of Bitcoin.  Basically, Distributive ledgers are an add-hoc standard database with security, transparency and access control more or less built in.  They're called Distributive ledger because the operate like a book ledger, which once you write into them, you can't alter the line entry and distributive because there are many, mirroring each other.

Healthcare data collected by a clinician or a device during an encounter is episodic, ledger style based.  Once it is signed off by the clinician or entered via a machine into the record, it must not be altered.  DL support this style of workflow by nature and provides a consensus strategy, which support non-reputation.   PGHD,  needs a non-reputable structure and assurance, in order to be trusted by clinicians.

My previous article's focus wasn't meant to be on EHRs, but PGHD or data that is collected without a clinician's assistance, i.e., the patient or the collecting device is outside of the doctors office.  In the near future, the number of devices collecting patient and environmental data about a patient will be astounding.  My hypothesis is based on the use of DLs to identify, maintain, securing and associate these devices with the correct patient.

The FDA mandates that medical devices utilize a Unique Device Identifier (UID).  I propose using the  UID as part of the digitally identify of the device in the ledger/chain.    The device's IDs could be assigned to a patient when the device is purchase or is provided by a clinician.  This would provide a solution for verifying PGHD and the patient.  IEEE 11073 also provide a facility for data provenance during transmission, which could also use the digital ID for identification

Patient/Human Identity is another "third-rail" in the USA, however it is supported by others countries and could be associated with a device's UID, which would make verification more reliable.   There are already companies developing DL/Blockchain human identity products.

The UID stored in a DL could be used to manage the devices.  Consider procurement of a device for a patient as an example.  The doctor diagnoses a patient with AFIB, an implantable cardioverter defibrillator (ICD) device is going to be inserted into the patient chest.   Before ordering the device the manufacture adds a UID.  What if the manufacture placed the ICD on a DL and recorded the UID on a new ledger.  When the hospital receives the device, the DL is updated with the new owner, the hospital.  The ICD would be assigned to the patient before surgery and the DL would be updated again with the new owner, the patient.

ICD have batteries, periodically they need to be replaced, this maintenance could be handled by a optional Smart Contract, i.e., a pre-programed solution to fulfill an agreement (replace battery). where that device notifies the patient and doctor that an event has occurred and an appointment could be scheduled for the replacement.

PGHD collected by a devices with a registered UID, which has been assigned to a patient, can now be access by the doctors EHR, via a link to the DL.   Using the UID as a Primary Key we could store the data in a secure distributed database such as Apache Cassandra. Storing the link to the PGHD data inside the DL for that device.  DL's access keys could be managed by the patient or the patient proxy, e.g., their doctor or healthcare organization.    When a patient wanted to see another doctor or change organization, they could provide a set of keys to the new doctor or organization, as well, revoke keys if they wish.

This solution doesn't contain all of the answers to this difficult problem, however our current solutions to handling interop has stumbled and the near term onslaught of devices leave us little alternative other than to look outside of the current infrastructure for answers.

Distributed Ledgers, the next step in Patient Generated Health Data (PGHD) including Environmental data

Soon we will be able to access thousands of datapoint into our lives, many will reflect our environment and health.  The HHS Idea Labs held a Entrepreneur-in-Residence webinar on December 13, 2016, for recruiting an software architect to assist the National Institute for Occupational Safety and Health (NIOSH) in collecting employment data as it pertains to a persons health.  They wish to share/store the collected data in the EHR.  Onerous at best, because most EHR today do not have API for uploading data and HL7 standards do not currently provide for discreet PGHD data. Why,  environmental data or other types of data that affect or is collected by the patient isn't considered clinical.  I am not saying this is a bad thing, for in data design, it is best to segregate data, especially large data sets.

The webinar panel mentioned FHIR, the REST API from HL7.  Currently FHIR datagrams are based on HL7 V2 which is not designed for PGHD (Patient Generated Health Data).  We are trying to use old technology and clinical standards for collecting and storing PGHD and IoT data .  If we are bound to the aging EHR design and HL7 clinical protocols, it will be impossible to develop a solution that will support the ever growing data lake, which is being collected.

We need a system that can collect, store and analysis IoT data or data from anywhere and anything that come in contact with the patient.  A distributed, secure solution, one which provides transparency and is patient controlled.  The solution is available now, the distributed Ledger, the database that support Blockchain.  Distributed ledgers store transaction data and distributed database like Cassandra store the payload.  This solution already provides a standard for sharing, securing and providing transparency for transactions such as data events.

This solution would allow EHRs, the client, to access the patient's data anywhere and anytime, using the credentials provided by the patient. All systems that affect or interact with a patient health could have permission to write into the ledger. An Example; NIOSH in 2004 published a toxicity Alert about employees that worked with popcorn flavoring. If workplace sensors data was supplied to the employees EHR, a doctor or an analytic platform could detect or predict issues such as obliterative bronchiolitis within patients.  NIOSH recently published another paper on a simular issue in coffee processing facility.  Consider the cost saving that could be realized if we could detect environmental issues in patients before the become health issues.

I am proposing using distributed ledgers as a secure reference and storage of patient IoT data.  EHR's would not have to change their structure. Vendors could consider a ledger as a third party solution with an exposed API for easy integration.   Analytics platforms could analysis data in background, searching for correlation within the data.

This solution could also be used to share patient data in a secure manner, solving the interoperability issue.  EHRs, with the patient's permission could share credentials, which would allow other systems or doctors to access that data. Since distributive ledger solutions are based on transparency, transactions would be saved as a chain-of-custody paradigm, providing non-reputable single point-of-truth.

Cloud based distributed ledgers can provide a ubiquitous shared database solution that will not impact a EHR or organization's health systems by adding new types of data or interfaces.  It will allow for a forward path of growth in health and science without compromising organizations security or patients privacy.