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

Interoperability, it is more than a set of interfaces.

Last week I had the pleasure of meeting Dan Pettus, VP of Connectivity at CareFusion, we were part of a Panel on The Future of Interoperability at the BIOMEDevice conference in San Jose, CA.  During our  prep for our discussion, Dan provided his view of interoperability, he said that it is more than an technical interface, but the relationship between two systems to communication on multiple layers as well being in sync with each other to the extent that if one side is not working the peer will be affected.   He provided an example,  let’s say that you have an infusion pump that is connected to an EHR and you receive a formulary update in the EHR, the infusion pump(s) must be updated ASAP.  Intelligence must be built into the system to recognize that the update must be sent downstream to the pumps and that the pumps themselves need to be aware of required updates when they comes online.

I had never really thought of interoperability this way, before our conversation.  Endpoint devices do have more than a technical interface,  the easy part of interoperability.  We must consider what other systems are affected when one side of the interface is updated.  We must also take into account how workflows may be affected with peer updates

 When we plan integrations of devices or systems we need to think about the unintended  consequences of interoperability.

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

First Open mHealth Summit, a success for mobile health

I was lucky enough to be invited to the Open mHealth Summit event in San Francisco to witness the unveiling of the latest mobile framework and protocol for healthcare. I have been talking with Dr Ida Sim of UCSF for a few years about there Open mHealth (OMH) project.  We both agreed that there is a need for a protocol/standard to transport data between wireless smart devices without the overhead of the land based HL7 standards such as CDA or CCDA.  Several years before meeting Dr Sim I decided to quit complaining about HL7, so I joined and started try to bring about change in mHealth from within.  When I first read about Graham Grieve's FHIR, a Restful API interface to supplement or replace the CCDA I was thrilled, and implemented a version in a project before HL7 got a hold of it.  HL7 FHIR attempted to solve some of the mobile issues but fell short IMHO by implementing XML and retaining  some of the legacy overhead from the CDA.  FHIR, is good solution for web based solutions that need to communicate directly with and EHR or mobile with 4G, however much of the world including the US doesn’t have 4G and the overhead is still quite high and many solutions do not need to communicate directly with and EHR. 

Dr Sim and her colleagues have a dream to simplify the sharing of health data and there are well on their way to doing it.  If what I saw yesterday is any indication of the future, Open mHealth is the direction to follow.   Open mHealth as it names states is open source, it is not a standard, however most standards do not guarantee interoperability and never will.  The solution is Restfull APIs with “standard” clinical templates to share meaningful data.  OMH already has many supporter that are helping to extend the platform.  Catalyst has a solution that converts OMH into HL7 V2 (circa 1989) the most widely used protocol of healthcare and back again,  now that is interoperability.  There is also a project, Granola to serialize Apple healthKit and that alone is worth the effort to check out OMH.  

OMH doesn’t solve all the Interoperability issues and they are not really trying to, however they are solving the problem of sharing health data and reducing the amount of payload that is transmitted with a mobile smartphone.  Getting the EHR Vendors to except the data or to share their patient data that is locked in their silos is still an issue. 

I am very hopeful and excited about the work OmH has done to date.  

Insurance companies don't get it, yet. There is a lot to learn about Aetna's CarePass failure.

I was very excited to see the rollout of Aetna's Carepass at the mHealth Summit several years ago.  I seem to be a great idea, however it never got any real traction.  I spoke to some of the people on the team and there was a lot of excitement.  I envisioned a platform to connect to their providers, patients and EHR but that never happen.  Like so many health platforms on the market, they took the safe easy way out,  providing support to patient facing apps,  WHO CARES,  let me reiterate WHO CARES!

Some of these supported apps are great, but it is proven that most are downloaded used once or twice and abandoned.  The only way to get patient to really use apps is for doctors to prescribe them and then have a facility to transmit and store the patient provided data to the provider's EHR.  However, that is still somewhat of a dream, which there is yet to be a standard to support.

In order for a platform to be successful it must be connected to the healthcare eco-system, that is, the provider's EHRs.  However not happening, most of the EHR cannot communicate with themselves.  This is where Aetna had a chance to make things different, they could have demanded interoperability and communication with patient facing apps.  Yes, there are a lot of issues around this but I believe they were well positioned as a payor to bring about change.

One of the hurdles that I did see with Carepass is getting other Payers or providers outside of the Aetna network to use their platform.  I don't think that this going to happen for a while.  Which is a shame,  we need healthcare organization to work together if we are going to get true interoperability.   We also need companies such as Aetna to keep innovating pushing the old school status quo.

Change will come, it has to.

Jeff Brandt
www.dekaG.com