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,  

"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.

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

“Secure by Design”, IoT in health

Though my subject is Medical Security, this post  extends to devices within our home, auto and our pocket.  If the device is connected we need security to insure privacy.

The most important step to ensuring our privacy and protecting our data starts long before you purchase a device or a new connected devices is added to a hospital or doctors office network.

Security starts in the design of the device and is based on software best practice, many that are not known or enforced in to coder community today. The practice is called  Secure Software Development Life Cycle (S-SDLC) an is taught in the first semester of most Computer Science college curriculum.  This is where I normally lose the Agile designers, but wait, this will work for Agile as well  We just need to consider the sprints as smaller circles/life cycles, more about this later.

There is one large caveat to designing medical software, if it fall under the FDA definition of a medical device it must follow IEC 62304, which is waterfall design, at least for the documentation.  Not all software for medical use need FDA approved, e.g., EHR Electronic Health Records do not fall under FDA jurisdiction, why?  Good question, however we will leave this for another discussion.

One issue software faces today is the lack of Computer Scientists,  there are many great coders doing good work, however the oversight seems to be lax.  Oversight is the responsibility of the vendor that owns the software and the customer who purchases the software, e.g., a hospital purchase a solution to store PHI, something goes wrong and the data is compromised.  It is the hospital responsibility to report and most likely compensate the patient's that have been damaged by the breach.    

S-SDLC

Secure SDLC is based on SDLC, a best practice for designing and delivering robust software.

A series of steps starting at the top of the circle describing the life cycle of the development.
S-SDLC  takes into account security at every step of the cycle, e.g., Requirements phase, add Security requirements.

One of the most important parts of the cycle is testing,  it is the last chance to catch a problem before it gets to the customer.  Because of the emphasis placed on iterations and quick to deliver, many coder today do not agree.

There is a V-Model for SDLC that stresses the testing phase, by including 5 levels of testing.  Many in the Agile community feel that this model is to close to Waterfall design,  I do not wish to debate, however I did want to show the testing phases that must be implemented in-order to protect data.

• 
  

• Unit testing
• Integration testing
• System testing
• User acceptance testing
• 
  

User Acceptance Testing is one of the most important phases because it test in a way that the customer will use the system.  I suggest that organization perform this testing themselves to make sure they are getting the protection and operation that was sold to them.

As IoT solutions become more available in healthcare, we will need to be more diligent in protecting our privacy and the privacy of our patients.  We can no longer except that notion that a product, service or vendor is secure, we must follow through and be sure.

Security isn't something that you can buy as much as it is a way of thinking, designing testing and implementing.   Organization must train their people to think about security first, in everything they do.  We also must implement system that allow employees to report suspected security problem without repercussions, i.e., shooting the messaging .  Security is a team effort, both strategic and tactical.

The passwords have met their match

Yesterday, it was announced that a Russian Crime syndicate has stolen 1.2 billion identities.  As of the next day it is was still not known where or who’s IDs were stolen.  The media is suggesting that we change all usernames and passwords.  I like many, have at least one hundred usernames and password and this would be no small feat to change them and most likely won't.  Many times it is difficult or impossible to change usernames.

One of the primary issues leading to all of these cyber attacks is that millions of places that passwords are stored.  Each website keeps your username and password on their systems.  There are systems (OAuth) that allow sites like Google and Facebook to share credentials with other sites to allow access to their systems without setting up new credentials, however that means you have to trust sites like Facebook to store your credentials.  Since these companies make their money from selling information via advertising, well you get it.

We must ask why these passwords were not encrypted? It was poor design and oversight.  Data at rest is always vulnerable; it is the “edge” that gets hacked, i.e., data can be sent over a secure links, such as SSL but when it is moved or temporarily stored during processing it vulnerable and if the data is not encrypted when stored, it remains vulnerable to thief.  Credit Card data before PCI compliance rules had the same issues.  Compliance, however isn’t a law such as HIPAA, but maybe it is time for legislation for all password data.

There needs to be a better system for identification and authorization.  Usernames and passwords have met their match, the well funded, sophisticated hacker, the new cyber criminal.

Jeff Brandt

www.deKaG.com