Patient Generated Health Data (PGHD) - The "Killer App"

Technology often goes hunting for a problem to solve, this becoming more evident as technology funding is skyrocketing, producing an environment of technological acceleration.   Healthcare technology fueled by the ACA and the need to reduce cost is in the forefront of the movement.  PGHD, the human endpoint for data collection and the place where answers lie, has been mostly overlooked in medicine, drafting far behind clinically collected data.   PGHD holds the verifiable keys to individual and public health, filling the gaps of clinical data.  PGHD along with IoT devices will provide a  contiguous stream of patient data becoming the"The Killer App" of healthcare and clinical research.

Recently the ONC commissioned Accenture to develop a draft Whitepaper on PGHD,  "Conceptualizing a Data Infrastructure for the capture, use, and the sharing of Patient-Generated Health Data in Care Delivery and Research through 2024".  It is currently in draft and a good overview of the PGHD landscape.  

What I find lacking in the draft is the upcoming deluge of IoT information such as, home and workplace environmental data along with endpoints such as vehicle OBR (On Board Reporting), which impacts a person's health.  It is predicted that we will have thousands of sensors providing bio and environmental data in the very near future.  How and where are we going to store and provide access to this data? How will it be authenticated and secured? Will it become part of our medical record? Who will own and manage the data?

Much of this data will be near real-time streamed data which will need to be cleaned, compressed and analyzed.  EHRs, which focus on the collection of clinical data do not have the ability or architecture to manage this high volume of non-clinical data.  PGHD data is unstructured, it doesn't follow standards such as HL7 or LOINC to name a few, and is mostly stored in proprietary data sets.  The data doesn't fall under HIPAA protection unless it is stored in an EHR raising the liability of the providers and organizations. 

Technology is ahead of the ONC timeline, by 2024 the end date for ONC adoption, I predict the amount of PGHD generated will surpass the amount of clinical data collected, swinging the pendulum of value to the PGHD.  Why, because data is where the answers lie, the value.

The growth cycle will probably need to be brought in two to three years based the current rapid development of sensors and IoT technology.  This will future stress the EHR vendors to attempt to accommodate this data rather than focusing on their core business of providing an interface for providers to access patient data.

Security and privacy are a major concern with IoT sensors and devices.  It takes an architecture that is built from the ground up to support remote client devices. A secure architecture which supports authorization, authentication, data-provenance, non-repudiation and transparency.

A new PGHD data architecture is needed to provide an interface between the EHR and the Patient's devices.  A platform that can scrub, analyze and format results and findings for a provider to access via a portal or EHR.  Health Record Banking may be the solution, a patient controlled standalone distributed database that is secure,  accessible anywhere, anytime and anyplace,  

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.

"Yes, you can drive your car with your feet, but why would you want to." #Blockchain

I was speaking with a VC the other day about Blockchain and he asked me, " what can it do for me that other technology aren't already doing?"  I asked him to elaborate"  He proceeded to mention we already have security, communication, interoperability (to some extent).  I retorted, yes, but they are failing, e.g., many breaches and most EHR are not connected.

Where I see a difference in Blockchain; it's is a simple, transparent and secure framework to solve a difficult problem(s).

Blockchain wouldn't store PHI, however it stores the location of the data, the links to the other associated record on that chain, and the hashcode which is used to verify the integrity and provenance of the data. The blocks are verified, non-reputable and the security is provided by Public Key Infrastructure (PKI).

The real reason to use Blockchain is the simplicity and transparency and yes, you can do a lot of the same things with existing models. Same thing that they said about horses when the auto showed up.

Distributive Ledger AKA Blockchain have been around for quite a while, Bitcoin just brought the technology front and center.  Application like Bitcoin may fail however the infrastructure that supports the application will stay around.

I like the old saying that my chief architect used to say to me years ago, "Yes, you can drive your car with your feet, but why would you want to".

If you are interested in reading about another use of Blockchain in healthcare check our  Peter B. Nichol and my submission to the ONC Blockchain Challenge, Birth of the CryptoCitizen for Healthcare in CIO.

Reference architecture for Interoperability that may work, A near green field

I meet with some people several weeks ago who are wanting to fix the Health Medical Record, Patient Generated Health Data (PGHD) and medical device  interoperability problems in the US. Currently and in the past, many organizations have been working on interoperability, however this new group is talking about a different approach, using more of a business approach, a "keiretsu".

The CEO asked me how I would go about fixing the problem.  As anyone in healthcare knows, this is a loaded question that can stir emotion simular to a national election.   I decide to take the road most traveled, until I understood their stance.  I suggested a gateway for interoperability using the Open mHealth messages as a least common denominator.  Well, it didn't fly.  They then described their idea, huh, bit of a hard sell, but maybe... A Keiretsu would take a lot of organization and agreement of many players, well I wish them luck in the US.

After leaving the meeting, I wished that I would have understand that they were looking for solution outside of the status quo and were asking for someone to lay it out for them on the spot.    This is not a simple question to answer, since one of these subjects alone is huge, but two or three.   I understand their frustration with me not being about to hand them a solution on the spot, however, there is no one that is going to pull an architecture out of their pocket.  This is a very difficult problem with many in HC making billions of dollars supporting the status quo.  Not to mention the behemoth of work that has already been done, e.g HL7, HIE and EHR vendors...  After thinking about the problem for a few days I decide to provide my version of a reference architecture for Interoperability.

Interoperability and most communication is based on the ISO layers:

Layer 1 Physical- Hardware
Layer 2 Data Link
Layer 3 Network
...
Layer 7 - Application, FTP and HTTP -  REST, HL7 FHIR, messaging

Layer 1-3 of TCP  handles the connection and delivery of packets/messages via a cable like MODEM for example. The majority of the rest of the discussion will be in Layer 7 and focused on TCP/IP and HTTP, the protocol that browses use.

There has been a lot of talk lately around healthcare Plug-n-Play (PnP) devices and interop.  This is the ability to plug in a device and have instant connectivity, e.g., a USB device.  From my experience as a data-com engineer for many years, Layer 1 through Layer 3 PnP is not difficult and has been done many times, e.g., when you plug a Bluetooth device into your PC it recognizes it, however it doesn't always mean you can receive the data that you want.  Mostly because the engineers and architect that develop these standards and systems have the mandate and support to interoperate and standards committees that understand hardware and software protocols.  Layer 7 the application layer is where the problems lies, there are a lot of different flavors of applications and skills needed to produce an application and many of these skills need little or no engineering background.

Healthcare HL7 V2, V3 and FHIR are very simular protocols using serial streaming.  V2 uses mostly universal asynchronous receiver/transmitter, abbreviated UART, V3 uses HTTP where XML  is the format that carry the payload, FHIR uses HTTP and XML or JSON for the payload.  None of them hold a huge advantage over the other except the skill needed to program the interfaces, let's say they are "Tightly Coupled".  None address the real problem of the semantics of the payloads, which have multiple standards of semantics,  Reference Information Model (RIM), OID, RXnorm for pharma, SNOMED for clinical terminology, LOINC for Labs.  Confused yet?   So, they all solve the connection part but not the language used to communicate.

Now back to the topic,  If you had the opportunity and x-millions dollar in support to correct this mess,  interoperability that is, what would you do?

My first inclination is to start over, pay engineers and healthcare domain experts (doctors, Nurses, Lab, pharma) to set down for an extended period to review and iterate.

The security of EHR recorder is a mess, sharing is a disaster, even one Epic cannot talk to other Epic systems, so I have been told by many that use the system today, even though most will not admit it in public because of None Disclosure Agreements.  Auditing of access is also an issue that must be solved to guarantee privacy.

 Distributed Ledgers (DL) technology, AKA Blockchain may provide the secure solution for sharing, auditing, messaging,securing and providing patient control of electronic medical records.   DLs are a simple open ledger or a database for tracking transactions and providing transparency.  Medical Record updates are mostly transactions,  New Patent, encounter(s),  lab results,  new prescription, discharge, billing...  Since a ledger entry cannot be updated or deleted, medical records using DL would provide a non-reputable and reproducible longitudinal record, simular to a HIE (Health Information Exchange).

Adding a DL as an additional Data Source, to a EHR should be simple, especially if the vendor used modern computer science architecture when they designed their system,  EHRs could still store a copy of the record in their database, nothing about DL would limit this.  Record transaction could be stored on a permissioned distributed databases, i.e., closed loop DL network for security.  All entries would use the same security hashing algorithm and by nature of DLs, forced to log any changes that were made to that record.  To keep everyone honest, validating the record,  verifiers, i.e., "Miners", chosen from participating organizations would monitor the transaction mathematically to provide consensus .

Plug-n-Play

PnP for DL connections should be as simple as signing up with an organization ledger system i.e., chain, getting credential (keys), downloading the API and integrating the API into your platform.  A Platform could provide APIs to the DL to provide an interface allowing the EHR to store records on the DL without interrupting service.  Basically the only thing that changed is the location of the data and the authentication process.  However, as I mention previously, the real work in interoperability is not the connections but, normalizing the semantics.

Authentication and authorization is handled with PKI.  The Holly Grail of Medical records patient controlled medical records.  With DL the patients could own and control the keys and share with their doctor or healthcare organization.  How the multi-key access would work is outside of the scope of the document.

We would then have to tackle the content or semantics, e.g., RXnorm for Pharma, LOINC for labs and HL7.   Refactoring of HL7 could be the first step,  rethink use things like OIDs, e.g, "2.16.840.1.113883.3.1", an id that takes up a lot of space and transmission power and not suitable for embedded systems or devices or wireless.  The semantics of the content is on of the biggest hurtles that must be address.  This is were implementers currently have options and options are difficult and costly for interoperability.

Solution:

1. Build Blockchain/DL permission network with off-the-shelve Blockchain solutions
2. Build or buy multi-PKI management system
3. Build a consortium of healthcare organization to participate
4. Only purchase or upgrade with vendors that support the framework
5. Audits and logs use Blockchain to provide chain-of-custody

Framework features:
   - utilizing Blockchain to authenticate with PKI
   - Encryption is provided
   - All transactions in a medical record are signed with Blockchain
   - All communication is authenticates with Blockchain

Future Solutions
  - Lab work uses Blockchain to authenticate
  - All Pharmacy scripts and fill use Blockchain to authenticate and audit
  - Medical devices are tracked and managed with Blockchain
  - IoT devices are tracked and managed with Blockchain
  - Blockchain Smart contracts are used to manage devices,
  - Billing management using Smart Contracts.

Blockchain in Healthcare, a solution for patient controlled records

Recently there has been a flurry of discussion and articles written on the topic of the use of Open source Blockchain in Healthcare.  The discussions have lead to a lot of misunderstanding and misconceived notions about blockchain and it potential use.

Blockchain was coined by the infamous BitCoin financial technology, which over the last few years shook the financial market and regulatory organizations.  Recently BitCoin was used to anonymously collect ransom payments from hospitals, such a Hollywood Presbyterian.  

Blockchain is bases on Distributed Ledger technology, which provides transparent distributed ledgers or databases in which to record transactions.  They are called ledgers because they can be used for sequentially storing debits and credit transaction for a financial application, such as BitCoin.  They are open and provide transparency to the transaction placed on the chain, however the associated data (payload) is encrypted and only the hash code of the data is visible.  The name Blockchain comes from the visual explanation of a steel chain, but instead of links there are chains of connected blocks. Once a block is placed on the chain it cannot be removed, same as a longitudinal ledger or record.    

Blockchain in the healthcare domain will have different functionality and features.  Bitcoin’s Blockchain an open public system, so that all can view transaction blocks on-line.  Healthcare Distributed Ledgers System (HDLS) could and most likely would be closed and shared only by healthcare organizations.  Though not needed, closed systems would likely get more support and reduce the FUD.  

Bitcoin's Blockchain is unpermissioned, anyone can use it. Validators, called “Miners” are paid for validating a transaction in a untrusted world, the Internet.   A Closed HDLS could be a permission system, using selected members of the system to validate the block.  As an example, consider a group of hospitals entering a trusted ledger systems, their membership would pay for the support of the networks.  Members would pay and chose their own validators to insure quality and nonrepudiation.  Quality and authentication would be provided via a consensus algorithm.

Distributed Ledgers also have the ability to facilitate a truly patient controlled patient record .   In this scenario, the patient could control the keys (PKI) to the records and could issue multiple keys to their healthcare organizations and revoke the access when the relationship is terminated.  The patient could also share or sell their records to research organization, reaping the benefit of sharing their data and providing better information to the research, i.e., non-autonomized data. 

The following is a list features and functionality of BC/DL

•  Signed transactions
•  Immutabe
•  Robust Security, PKI, Encryption
•  Longitudinal records providing data provenance 
•  Private consensus
•  Build in auditing 
•  Secure Peer-to-Peer
•  Nonrepudiation 
•  Distributed database
•  Smart Contracts - for billing, device provenance, Device Mgnt
•                                 AutonomousDevices
•  Transparency
•  Time stamping
•  Continuity of Care
•  No Single point of failure
•  Reconstructible Chains if a node fails
•  Peer-to-Peer communication             

Blockchain or Distributed Ledgers are not a panacea for healthcare security and interoperability, however it is a technology that has a logical fit and may produce a simpler, cheaper solution than the current system and deserves to be considered. 

Jeff Brandt
Speaker, Blockchain Symposium June 9, 2016

Secure Cradle to grave Electronic Medical Record WITHOUT disruption, Distributive Ledgers. AKA Blockchain

The latest hack of Hollywood Presbyterian Medical Center again bring to our attention for the need of security in healthcare to be updated.  The Current system is failing! Distributive Ledgers an architecture that supports Bitcoin, which is called Blockchain, could provide the security and control of patient records and providers communication.

 One of the issues with modern Electronic Medical Records (EHR) is the inability to interoperate.  HL7 standards organization has provided protocols for transmitting the information, however that is only a small part of the problem.  Issue such as provenance, Digital Signing, content management, identity and encryption to name a few, inhibit easy sharing of data.   There is now a technology that could eliminate the majority of these issues and provide us with the promise of a Cradle-to-Grave EHR, that is Blockchain.   


Blockchain is the OpenSource technology that support the somewhat infamous Bitcoin.  Regardless of your opinion of Bitcoin, Blockchain technology is a very viable open distributive ledger solution.  Blockchain provide a P2P (point to point) encrypted realtime mesh network, where transactions are timestamped and verified on an open ledger system.  Consensus is the system used to validate the integrity of a message or document, each time a document is altered, a new block is added to the chain providing a linear and reproducible record of access and updates via a hashing function. 

I mentioned "without disruption" in the title because, health organizations have suffered a lot of disruption in the last few years with the advent of the EHR requirements.  I believe there is a better way to design, using an adjunct processor solution, i.e.,  by providing interfaces to the EHR via HL7 FHIR and providing a Blockchain API, the EHR can use a Blockchain without significantly disrupting their EHR installation.  

To answer the question of the Blockchain records, there are many solutions already available for storing records on open Blockchain, the Bitcoin chain. however, even thought blocks do not contain readable data, it may be optimal to store the records on private Permission networks, such as hospital networks and validate via consensus process or Paxos, such as, Practical Byzantine Fault tolerance used by Hyperledger, 

The following are some of the feature that would be provided to a medical record using Blockchain:

• Data Provenance

• Non-repudiation 

• Digital Signing of charts/records

• Linear chronological tracking, Audits records 

• PKI cryptography/encryption 

• Distributed decentralized, encrypted P2P messaging network 

• Identity management

• OpenSource

• Ubiquitous sharing of data

• No Single Point of Failure 

• Realtime transaction

• Content Management

• Public Records - Birth to Death longitudinal record 

• Uses ‘Proof-of-Work’ technology 

• time-stamping 
• 
  
• Private or public chains
• 
  
• Distributed databases