Storage Format

An EHR system's main purpose is to store and update health records. So if you want to build an EHR system, your first thought will probably be - what exactly is recorded in a health record?

I was quite surprised to find out there is no standard definition for a health record. Most people I talk to outside of the medical field are also quite surprised by this fact. Unlike an audio file, image file, or text file - there are no industry standard file formats for medical records.

So what information should be stored in a medical record? Some of it is expected. For example, here is some generic information commonly found in New Zealand primary care records.

However, this is just a medical record - not a health record. If a surgeon tried to use this record, they wouldn't know where to put their procedure details, or a physiotherapist wouldn't know where to track their patient's muscle strength. The information a GP needs is very different to what a hospital needs, to what a physiotherapist needs. All of these medical institutions deal with very different information, so all of their records are, by nature, very different.

Karsh et al (2010), state that a user's needs of their software can change tremendously between:

• Clinical Roles (nurse vs. physician)
• Clinical Situation (acute vs. chronic care)
• Clinical Environments (intensive care unit vs. ambulatory clinic, etc.)
• Institutions (Auckland Hospital vs. Wellington Hospital)

They conclude that,

"To succeed in today's team-based healthcare reality, health information technology should ... recognize that each member of the collaborative team may have different mental models and information needs, and support both individual and team care needs across multiple diverse care environments and contexts."

For this project, I have decided on my own definition of a health record.

A health record contains any information relevant to the patient's health - as defined by their medical staff and themselves.

This means that I cannot exactly define what information will be stored, or could be stored in the future, and that must be considered in the storage format.

Concepts

As this xkcd comic points out, perhaps it would be better to support an existing standard than creating a new one. The most promising standard I've found is FHIR (Fast Healthcare Interoperability Resources), from the HL7 organisation (Health Level Seven International).

FHIR provides a standard format for most healthcare record cases. It is by design, an extensible system - it is designed to be adapted for local usage, so a FHIR record (or resource as they call them) from France would be different to one from Auckland.

FHIR is more than just a record format however - it also provides standard REST apis for sharing medical records through HTTP. FHIR however, does not handle securing or authenticating the api, that is up to the implementor.

However, FHIR is not designed as a storage format - it's designed as a common format to help reduce the issue of interoperability. For example, say you wanted to move records between system A and B, which both use different record formats. First, you would convert the A records into FHIR, and then from FHIR into B records.

Peer to peer technologies have provided some of the most innovative data storage systems since the creation of the Internet. Blockchain technology has had the biggest impact in this field since the original BitTorrent protocol. The blockchain is a distributed database most famous for powering the crypto currency BitCoin. It's cryptographically secure, and able to scale to worldwide usage while being independent of any government or governing body.

So why not store health records in the blockchain? Simply because the blockchain itself is not designed for large scale storage. It is essentially a shared ledger - it works because every single user can keep a whole copy of the ledger for verification. This is why it's best suited for things which don't take up much data, such as transactions - as of writing, the bitcoin blockchain contains over 180 million transactions, but that only takes up 97gb.

There has been projects attempting to store medical records on the blockchain (Ariel Ekblaw, 2016) - however, in reality they're using the blockchain as an authentication system, which sits above existing storage systems. I discuss this idea further in Authentication.

If a health record is essentially a collection of medical records, why not store it as just that. Instead of trying to define a singular record, define a health record as a collection of separate modules, which work together to build a record.

For example, a very simple primary care record for our patient Alice could be made up of the following modules

Each module has a defined format (a Schema for programmers). For example, the admin module contains general information needed for patient administration, and could look like this:

The main idea behind the modular format is that it would be Extensible. Say for example Alice's record is opened by her physiotherapist. There isn't a good place in her current record to track her rehabilitation. Or say a surgeon wants to write procedure notes about a surgery - there isn't a place for past procedures. Say Alice wants to put her self-tracked diabetes data into her record - there isn't a module in her record for it, so why can't she add her own?

If users could define their own modules, then there is no limit to what information could be stored in a health record. If a patient, or any health professional around them thinks that some piece of information is worth storing, they could add it. However, I'm not suggesting every doctor starts writing their own formats. The idea with modules is that they are community run - if you define a module, you put it online in a registry, for other people to use. Chances are, Alice's Physiotherapist could just find a rehabilitation module that he likes on the registry, and add that to her record.

There are precedents of a community run module system working well in the context of software development. "Package Managers" are community run systems for the sharing of modular pieces of code. Say you wanted to write a piece of software, and it needed to format a date value as something easier to read, such as "three weeks ago". You could write your own system to format the dates, or you could find a module that somebody else has already made to do it for you.

Node Package Manager (npm, Inc, 2014), is a package manger for the programming environment Node.js. As of writing it has about 370 thousand modules, and the most popular module is downloaded about 1.6 million times a day. Other than illustrating the success of these systems, it provides a sense of quality. If a module has been used that much, it must be dependable and error free.

Within the context of a health record, modules would work in a very similar way. They'd be community run, and community improved. However, instead of being small programs, they'd be templates for sections of a health record.

Version Control

There is one other key features our format must support - Version Control.

There are very few good reasons to actually delete information from a health record. If there is information to be removed, it should be able, but the information shouldn't actually be deleted from the file. Information which might appear to be irrelevant at the time may become relevant in the future. Incorrect information should be able to be updated, but a history of what that information used to be should be kept. There is the argument that inappropriate comments should be deleted - but how can a file tell between removing a snide comment versus covering up information of medical malpractice?

Version Control system have been in successful use for years in other fields. For example Git (Torvalds, 2005) provides version control and team collaboration for code, which is used extensively in software development.