![](https://i.imgsafe.org/0746eb224f.png)![](https://i.imgsafe.org/073d6de434.jpg)

# 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
1. 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.
1. 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.
1. 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
1. It gets too big to deal with
2. It can get corrupted if a write fails
3. It can get modified without detection
4. 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.