Preface
This article is my attempt to gather my thoughts on the topic of where to store an individual's medical record. I feel confident that FHIR is to proper format, but the issue of centralization poses a major problem / threat to individual health data. At the same time de-centralization poses an almost equally dangerous threat due to the sensitive nature of this data. I plan to explore the this topic in depth.
Why does this matter to Society?
Well, it matters because life is different now than it was 30 years ago. When I was a kid, I had my doctor and I had the hospital. It's possible I had a specialist, but on a very real level, there wasn't much need for me to carry around my medical history. My general practicioner knew it all because he generated it. Let's not forget the fact that none of it was electronic. Most of it wasn't even typed. These were handwritten notes detailing my height, weight, bloodpressure, temperature and whatever medicines I was prescribed for whatever diagnoses were delivered.
It's really different now. I for one don't really have a regular doctor that I visit. I may go to a minute clinic or Urgent Care if needed. Each time I enter a new building, I have to fill out new paperwork and answer 30 questions. The doctor has none of my history and honestly, I have no good way to provide it to her. I mean, even if I had a CD or USB Drive with everything on it, my doctor's medical systems couldn't ingest it in any meaningful way. Let's be clear through, it's a total pipe dream to imagine that I could actually have a USB drive in my hand that contains my entire medical record in a clear, concise, accurate format.
So, let's explore why this is such a monumental undertaking. We will need to break this into some discreet areas in order to be able to grab on. How do you eat an elephant? One bit at a time.
Data Intake
When you show up at a medical facility, you check in and register. Often this happens with a paper form which is then manually entered by a staff member. Once it's entered, it is stored in an EMR system. This system likely stores all your data in SQL like tables. This step is largely gaining traction and there aren't many hurdles to the momentum continuing to build. Each of these EMR systems store the data in their own way and have their own workflow and reporting. Hospitals invest millions of dollars in these systems.
Data Sharing B2B
Let's clarify with an example. If you get a CT scan at the hospital, it's common for the radiologist to not actually be present at the hospital. In this case, the Hospital's EMR system needs to send your super high resolution scan elsewhere so the radiologist can view the scan on her computer. HL7 is a standard used between Medical Systems to transfer information and even attached files like radiology data between one another. This data sharing is overly complicated because HL7 does not have a widely adopted encryption standard so what you find is that systems cannot just send HL7 to one another. Rather, the IT teams in each organization must set up ineffiecient IPSec Tunnels for the sole purpose of connecing these cleartext HL7 channels. This becomes further complicated because of some inherent ambiguity in how different organization interpret fields in HL7. In most cases, this HL7 must transit something like Mirth, Cloverleaf or Iguana to perform translations on the data in order to ensure that both sides can keep their own verison of the truth while still being able to accurately interpret the meaning of the other side.
B2B vs B2P
As you can see above, problems encountered in the interpretation of data can be solved with brute force (manpower, software and hardware). That's all quite possible in the B2B models. Business are around to make a profit and ensuring data is accurate promotes efficiency and ultimately the bottom line. B2P gets a little trickier. First of all, this information can't go to some proprietary system if it is to be delivered to an person. The data needs to live in it's raw form ideally without even a database layer. Think aboui it for a minute. What if your medical record data could live as one huge text file, a text file that adhered to an open, accepted standard and could be frozen in time as new records were added onto it. What I'm describing is essentially a blockchain of FHIR HL7 objects stacked on top of one another. Imagine that you could give your doctor or hospital your public key (much like you can give out your public Bitcoin address) and your provider could simply write out Observations, Medications, Diagnoses, Insurance Claims directly to your private (encrypted) blockchain. You could literally hold your entire medical record in your hand in a universally accepted format. You could easily give your Doctor access to your record by authorizing an iPhone or iPad app to transfer and decrypt the blockchain where you could carry on an enlightened discussion based on your medical record facts.
Why is this possible now?
There are two relatively recent developments that make this more soable now than they have been in the past.
FHIR Standard
The FHIR standard is an HL7 based standard but it has three huge advantages over previous generations
- It is RESTful. RESTful operations make the world go around. This is how machines talk to one another. EMR A can request a patient demographic record from EMR B in a fraction of a second over the Internet with an agreed upon syntax.
- The FHIR standard used JSON. Once again, JSON is a database-like syntax used to communicate structure and concepts across the Internet almost every time you make any kind of purchase on the Internet. It's time tested, fast and efficient.
- This RESTful / JSON protocol can be sent across the internet via https, the very same protocol you use when browsing the web. There are no firewalls or roadblocks set up to block https port 443.
Blockchain
Sure, we always had text files, but the problem with appending and appending and appending to a text file is that
- It gets too big to deal with
- It can get corrupted if a write fails
- It can get modified without detection
- It can simply get lost or deleted
The blockchain is like a really kickass permanent record. Once something is written to the blockchain, it's there for good. Sure, it can be amended but the original is still always there with an audit trail. The blockchain is generally corroborated by multiple computers. This adds another set of checks and balances. The blockchain provides a uniquely well-suited mechanism for layering Patient data onto.
- Visit the Doctor Encounter Transaction
"fullUrl":"http://fhirtest.uhn.ca/baseDstu2/Encounter/5164",
"resource":{
"resourceType":"Encounter",
"id":"5164",
"meta":{
"versionId":"1",
"lastUpdated":"2016-03-14T16:31:16.791-04:00"
},
"status":"finished",
"type":[
{
"text":"OutPatient"
}
],
"patient":{
"reference":"Patient/5149"
},
"participant":[
{
"individual":{
"reference":"Practitioner/5144",
"display":"Dr John Doe"
}
}
],
"period":{
"start":"2016-02-15T21:34:54.437Z"
},
"reason":[
{
"text":"headache"
}
]
},
"search":{
"mode":"match"
}
}
- Your doctor takes your blood pressure and heart rate Observation Transactions
"fullUrl":"http://fhirtest.uhn.ca/baseDstu2/Observation/5234",
"resource":{
"resourceType":"Observation",
"id":"5234",
"meta":{
"versionId":"1",
"lastUpdated":"2016-03-14T16:31:17.248-04:00"
},
"text":{
"status":"generated",
"div":"<div xmlns=\"http://www.w3.org/1999/xhtml\">Respiratory Rate, 29 resp/min</div>"
},
"status":"final",
"code":{
"coding":[
{
"system":"http://loinc.org",
"code":"9279-1"
}
],
"text":"Respiratory Rate"
},
"subject":{
"reference":"Patient/5149"
},
"effectiveDateTime":"2016-03-14T16:34:54-04:00",
"valueQuantity":{
"value":29,
"unit":"resp/min"
}
},
"search":{
"mode":"match"
}
}
- Your doctor diagnoses you Diagnosis Transaction
Diagnosis JSON
- Your doctor writes a prescription Medication Transaction
Medication JSON
Due to the nature of FHIR and RESTful transactions, these operations can literally stream to your blockchain in realtime as your doctor is entering them into his EMR. The EMR would simply need to be FHIR compliant and have permissions to write to your blockchain with your public key.
Privacy
This is where my lack of knowledge starts to hurt my analysis. Most blockchains are set up as public ledgers and, as such, leave all data publicly auditable. This clearly cannot be the case with a health record. The JSON objects written to the blockchain must be encrypted. This could work with a public/private RSA key methodology. Essentially, if the providers are holding your public key, they could encrypt the data and write to the blockchain based upon that key. Since the user would hold the private key, it could be used to unlock the encrypted data written to the blockchain.
Concerns
As with crypto-currency, one of the toughest parts about education is explaining security. People are so used to having a fallback, a way to recover their card, access tehir account, reset their password when then lose access. But as we know, if you are going to trust a third party to help you recover your keys, you must implicitly trust them to not misuse your keys whether intended or not.
Software EMR vendors who intend to write medical data to a user's blockchain would need to undergo a certification process to ensure that they were FHIR compliant. This would require a sandbox and a formal certification process.
The transmission of the public key from patient to the provider would need to feel easy and seamless. User enters doctor's office, opens phone, maybe sees a beacon requesting the medocal record. User confirms with thumb print and the operation is complete in 10 seconds without a coordinated effort required.
Conclusion
BlockChain technology coupled with a means for describing heathcare in JSON format presents a unique opportunity for a patient medical record to live on an open platform agnostic format. While there are a few hurles to overcome, they are much smaller hurdles than in the past.
Sounds like you have identified a business opportunity. Are you going to go for it?
I need a solid blockchain guru who would be interested in investing their time and energy in this product. Yes, I am interested in pursuing it.
I know some people at the Philips Blockchain Lab in Amsterdam who might be interested. Would you like an intro?
Yes, I would. Sorry for the delay. I've had some issues with Chrome and Steemit lately.
It's a great idea, but before you invest any time in making this happen, I'd suggest addressing the privacy concerns somehow. I know that in the US, the privacy of electronic medical records is governed by a law called the Health Insurance Portability and Accountability Act (HIPAA). It's pretty strict, I think. Could the material be encrypted somehow before going on the blockchain? The issue is that the hospitals and insurance companies, etc., would have to be satisfied that they would not be in any HIPAA danger, otherwise they would get sued. Outside the US, there may be places where you'd have less of an obstacle. Maybe someody else knows more about those?
Here is the agency's summary of this part of the law:
http://www.hhs.gov/hipaa/for-professionals/privacy/
The reason I know this is because I had some records leaked once!!!
HIPAA is the big one, but it doesn't end there. FERPA for college students. And some state laws also. Or just stay away from the freaking US bureaucracy and do it somewhere else. Your idea has merit, but medical records would be the most difficult place to start. I'd start with some other types of records, putting those on the blockchain. Lots of them are public: birth, death, marriage, wills, etc. Try to find a business niche there and then expand it, would be my suggestion.
Well, technically, once your medical record is in your hands, it is up to you to secure it. That's part of the beauty of this solution. The goal would be to put your medical record in your hands securely. Once that is done, it's up to the individual to keep it secure...or not.
I recently finished a residency program in the U.S. (onto an informatics fellowship). I've actively tried to generate some interest in such matters but upmost problem is that doctors just want to practice. Most of doctors generate high enough salary to not bother being interested in improving workflow. Progress is sluggish. I was in program affiliated within the top 10 US hospital, but even getting the most routine data for quality assurance was like pulling teeth. We still use paper forms everywhere because it's easy and secure (yes storing data somewhere is insecure by default)
Added to that, there political battles between larger hospital organizations preventing usage of standardized protocols. The standards like HL7 exists but causes a big problem for clinicians because it ends up as a checklist of items - a logistical burden dumped onto clinical caregivers - it's not their domain. We are supposed to be as fine in terms of granularity as possible. Standards end up funneling our assessments into strict categories, hindering new areas of research. (i.e If a new subtype of thyroid cancer is discovered to be separate and behaves very well without chemotherapy, but based on standard checklist we have no way to backtrack these patients, because that entity does not exist because clinicians checked off the generic version of thyroid cancer based on the 'cancer checklist').
Secondly, EHR market has been monopolized by Epic to the point of a proprietary platform becoming the norm (they actively prevent other vendor machines from accessing their API). Medical field is not 'hot' like tech industry, where we're blessed with developers flocking to develop a new hot platform. Because of the complexities, security issues, we go with the safest choice: Epic. They are one of the most anti-open source EHR makers because they make money off custom module creation. I shouldn't be so harsh as they do have one of the best EHRs (akin to Windows of the OS market, gets bashed all the time but its a good OS if you think about adoption and usability).
These are some of the issues to be addressed and thought about prior to jumping in thinking blockchain in medicine. We are lightyears behind unfortunately. But I would also like to change that!
@plasmak thanks for the post. I've heard that Epic is not much of a team player, but they do have a pretty nice set of open standards published at http://open.epic.com, including a growing library of FHIR based objects.