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:
- Build Blockchain/DL permission network with off-the-shelve Blockchain solutions
- Build or buy multi-PKI management system
- Build a consortium of healthcare organization to participate
- Only purchase or upgrade with vendors that support the framework
- 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.
