Authentication & Privacy

Authentication has two main purposes - verifying the identity of the user and protecting the patient's privacy.

Authentication Strategies

There are many different ways to verify the identity of a user. Here is a quick overview of some of the most common methods (Pandya, Narayan, Thakkar, Madhekar, & Thakare, 2015), (Kamarudin, Yussoff, & Hashim, 2016).

Email + Password Common method, used by services such as Facebook, Twitter and Google.
Multi-factor Authentication Multi-factor checks for several separate pieces of evidence of identity before allowing access, ensuring a much more secure login. Typically, two things are checked - knowledge (such as a password), and possession (such as a cell phone). A common example are ATM machines - you need to know both your PIN, and physically have your bank card with you.
Passwordless Passwordless logins will email or text you a temporary, unique password which expires in a short time frame.
Physical 'key' Physical objects can be used to verify identity - an example are key cards, which are commonly used as locks on doors (such as in a hotel).
Biometric Biometric authentication works by looking at a unique physical feature of the user - such as a fingerprint, face, or iris.

The question of 'what method is best for an EHR system', is tricky, as EHR systems can be used in so many different contexts.

For a GP logging into her computer every morning, multi-factor authentication would be easy, and secure. However, imagine a nurse in a hospital, who has to switch between many different computers as he moves through the ward - it would take forever. In that case what would be the best would be a physical keycard, which would enable him to log into any machine with one swipe.

And imagine the patient trying to log into a patient portal to view their records - they might not do this very often. It would be easy for a password to get forgotten and lost among the countless digital services we use in our modern lives. What might be much easier for them would be a passwordless system, where a temporary login link is emailed to them, or a code sent to their phone.

In order for an authentication system to cater to the range of use cases in Healthcare, it needs to be designed with multiple strategies in mind. By allowing institutions to use what authentication strategy makes sense to them, ensures they can balance security, and ease of use for their staff.

MedRec

MedRec is a very interesting project, which uses Blockchain technology (which powers Bitcoin), as an authentication layer for health records. While this project certainly fits my requirements for being experimental, I don't think it's appropriate for my project, for the following reasons.

MedRec is an authentication layer, which sits on top of provider databases. So a patient's health information isn't stored in the MedRec Blockchain - it only contains the authentication information. While this ensures the authentication is cryptographically secure, there is no guarantee the provider DB is secure. They do recognise this as a caveat, "MedRec does not claim to address the security of individual provider databases where the record content is stored. This must still be managed by the local IT admin".

The value MedRec provides to patients is a single authentication identity which can work across multiple institutions and providers. However, what value does it provide to institutions and software providers? Medical researchers are provided with value by gaining access to anonymised metadata in exchange for computational resources (mining) which sustains the network. However institutions and software providers - the stakeholders who have to make the largest changes, aren't provided with any strong value.

Institutions would have to make changes to their workflows due to the new software - and software providers would have to re-implement their authentication layers. Both are non-trivial tasks.

MedRec is really interesting research, and I hope research in this area continues - but for my project, I believe it adds too much complexity, without creating enough value.

Filtering

It's also worth considering how information in a record can be 'filtered', depending on the user. This is for two reasons:

Privacy. Healthcare information is inherently sensitive information for patients.

There are varying levels of sensitivity - for example, a patient's medication list should only be shared with medical professionals who are caring for that patient, but all parties should have the most up to date list possible.

But at another extreme, some information is shared with only a single medical professional, in complete confidence. This is because the information could be embarrassing, have a huge mental effect on the patient, or otherwise.

Relevance. As a GP I interviewed noted, Bryan, not all information is relevant. He could understand the value of EHR systems, but he was also concerned with his records being filled with information that would mostly get in his way.

He gave the example that while it would be useful for him to know his patient visited a neurologist - the full details just aren't relevant to him, and would have no affect on how he treats his patients.

How filtering works will depend a lot on how the information is structured. If the data was structured into 'modules', as I suggested previously, it could make sense to filter on a module to module basis.

Access

As much as authentication is about ensuring the incorrect people can't access records, it's also about allowing access to those who need it. So far this chapter has mostly been about authenticating medical professionals - but what about the patient?

As a personal experiment, I requested a full copy of my records from my GP. The process was quite involved. First, my GP had to approve the release of my records, so I discussed it with him at a regular checkup. He was quite happy to hand over my record, but just wanted to discuss why first. Then after a few weeks, I received an email containing a locked ZIP file. After replying to the email that I was indeed Eliot Slevin, they sent over the password. Inside the ZIP was a PDF file of my entire record. It was formatted to be printed on 86 A4 pages.

Reading my own medical record was a strange experience, as my visitation notes dated back to my birth - 22 years. It was a bizarre trip down memory lane of my sicknesses, accidents, and otherwise. However, it was completely fascinating, and I highly suggest to anybody who's curious about reading theirs, to do it.

Accessing my record like this had its drawbacks. Firstly it took an extended period of time, and secondly the format of a PDF isn't that useful. It would be hard to take that data and use in in a software program, visualise it, or analyse it.

Patient portals are a great way for patients to access their records. The patient's functionality can include viewing their record, but can be extended to booking appointments, requesting repeat prescriptions, and even messaging their GP.

A Nurse Manger I interviewed, Olivia has found great success with their patient portal. It's very popular, with 70% of their adult patient population is signed up to use the patient portal. A common thought is that digital solutions such as patient portals aren't used by the elderly - but there is certainly demand. The first patient they signed up was 80 years old, and he's still using it.

Patient portals are great for patient accessibility to their record, and their healthcare provider, but they don't do much in the way of allowing data access in a programmatic way. In order for me to extract data from a patient portal, I'd still have to manually copy the data out.

The OAuth 2.0 protocol (Hardt, 2012), enables a third party limited data access. It's currently used by some of the largest Internet services such as Facebook, Twitter, and Google. For example, here is a screenshot I took of Twitter's current oAuth dialog.

0Auth would be a good choice for a protocol to allow 3rd party access, for several reasons.

Familiarity. 0Auth is used by many different services, and it's a system which many patients are already familiar with.

Authorisation rules. 0Auth doesn't just allow you to authorise a service to use your data - it can also be used to customise what aspects of the data they have access to. For example, Twitter explicitly says what information the application will be able to access, and what it cannot. This flow will ensure that it's explicit what information they're authorising access.

There are many cases where this would be appropriate. For example, in many aspects of care medical professionals will ask patient's to keep a 'diary' of their condition. For example, a headache specialist could ask a patient to track details of their migraines, so they can see what factors have an effect. A smartphone app could be designed specifically for tracking migraines, and allow the information to be automatically written to their official medical record. Physiotherapists could use apps to allow patients to correctly track their muscle recovery after injury. Perhaps one day, machine learning services could be created to instantly give you insight and feedback into your health based off of your medical record.

Platforms to build 3rd party healthcare software already exists, such as HealthKit (Apple Inc., 2014). Healthkit provides a platform for app developers to track, and store health information on Apple Devices, such as the iPhone. Healthkit can be used to track sleep, exercise, heart rate, and any other type of data. But, what Healthkit can't do, is add that information to patient's official health records.

I have personally tracked my sleep for many years with my phone - it's easy to do, and provides me with valuable insight. However, there is no way currently for me to add this information to my medical record - despite being information about my health.

Patient-facing healthcare software has the potential to change how we consume healthcare - or maybe it won't make a difference at all. But either way, without having the systems in place to attempt it, such as OAuth logins, we won't find out.

There is a wealth of potential discoveries to be made through statistical analysis of medical records. In 2012, a team of three discovered unique drug interactions by analysing open medical records provided by Standford University (Tatonetti, Ye, Daneshjou, & Altman, 2012). Despite using only statistical methods, they found suggestion of a biological interaction.

Ensuring that it's easy to collect the information for this type of analysis to undertaken is worthwhile. The value of this is not only for researchers, but public health experts, institutions, and policymakers. Being able to easily collect large-scale medical information which can be easily analysed or represented has value for many stakeholders.

Automatic anonymisation tools would be a simple way to facilitate this. This tool would automatically remove personal, or identifying information from records. It would allow institutions to easily hand over, or publish data.