Ade Memoire

I was at a meeting the other day about the new e-Referrals project – the one that is replacing Choose and Book.

Every initiative nowadays seems to involve a piece on how we can get patients interacting with it online. So, in the workshop part of my meeting, there was talk of an "app for that".

As some people will know, University Hospital Southampton NHS Foundation Trust has done some work with Get Real Software’s Instant Personal Health Record, to link the trust’s electronic patient record with the Microsoft HealthVault platform.

University Hospital Southampton’s approach

When we initially started looking at an online presence, we realised that it would be difficult to identify patients and link them safely with their UHS record.

From there, we also recognised that we would (potentially) like to use or create an account that could be effectively used to authenticate a user across a number of different healthcare related sites.

Having decided that the idea of a UHS identity would be difficult to sell to the wider market, we went to look for a system that would give us the things we wanted, and found Get Real Health and its arrangement with HealthVault.

The Get Real Software product (the Instant Personal Health Record) is a content management system that can be used to build pathways, and comes with a number of out of the box functions such as ‘questionnaire’ and ‘diary.’

The link to HealthVault both enables patients to share information with others and to input health readings from appropriate devices.

This effectively gives a patient their own identity and personal health record, that they can then choose to link with any number of compatible sites, sharing their information with whoever they choose. There is now a mobile app, too.

Build it…

We chose to work with just two of our clinical teams on the initial proof of concept and have around 50 patients with inflammatory bowel disease and maternal (gestational) diabetes on board.

This has been a difficult project to manage in terms of predicting benefits, but I am reminded of the model that both Facebook and Twitter adopted when they first launched. Get the users on, and using what you have, and then start to exploit the benefits.

In our case, we assume that benefits that will emerge through interaction with patients. After all, at the moment our patients attend 350,000 outpatient appointments per year, and there are potentially many things that a patient could take advantage of, once they have an account with a provider website like ours.

A few ideas include: making sure that data is accurate; giving consent to others to see and share data; signing up for clinical trials; saving clinic time by filling in forms online; completing questionnaires – for example for outcome feedback; making use of online messaging and consultation; and exchanging documents – for instance copies of correspondence and discharge summaries.

Some of this is trivial, once the patient is online, whereas some of it requires complex functionality or interfaces.

Broadly speaking, sharing data, improving data quality, and form filling are simple, as is exchanging documentation such as letters and discharge summaries. Booking of appointments is quite complex due to slot availability and other issues; and that’s before you get into getting the patient administration system supplier to build you an interface.

And they will come?

In the short term we would ideally like to grow the existing 50 or so proof of concept users up to around 5,000.

But what is proving to be difficult is identifying the triggers for doing that. What is it that makes a patient want to sign up to a health organisation’s website, and how do we get that to happen before we have even seen them?

Small groups of highly interested patients who have long term conditions stand out as a clear opportunity, but that doesn’t really take us to the numbers we want to achieve. It’s not an “across the board” approach.

If a patient has been referred to see a consultant in outpatients, they will be hoping for a quick turnaround. Why would they want to go through the rigmarole of creating an identity just so they can fill out assessment data for us?

So what are the triggers?

The e-Referrals project has a strong link with what we have already been doing. We have been working on an appointment cancellation and rebooking piece, and have purchased an interface with our eCaMIS patient administration system to allow this to happen.

We will be allowing patients registered with our website to use the functionality. Hopefully it will be popular, and a trigger for registration.

However, it dawned on me during the e-Referrals meeting that if, nationally, we are going to have a system that patients can log-in to and manage their booking, then we definitely do not want them to have to create another account to log-in to our [University Hospital Southampton] website when they come to have treatment with us.

They should be able to use the same credentials, in a so-called federated identity structure, to log-in to both the e-Referrals site and the other services that are involved in delivering their care. The good news is that this is quite possible; but it must be put in place at design time, otherwise a valuable opportunity will be missed.

One set of credentials

It would be so much easier for secondary care providers to pick up the online service with patients who effectively already have an account, or online identity.

A patient’s interaction with us, as with any trust, is hopefully a swift encounter involving a couple of visits and no long term relationship.

In my own online life, if I am purchasing something from a website I have no intention of going back to – a one off thing – then I will usually try to get out of there by paying without creating an account.

This is because I don’t really want many random shopping sites holding data about me, and because there is no point in saving account details and passwords for sites I am not intending to use again.

I would predict a similar behavior pattern with patients and secondary care websites. I therefore believe there are good reasons for having a persistent identity. This, of course, could also be used to access GP data. Credentials that are used for multiple things will achieve a higher sense of value.

Federated identity is not a new concept. Many readers will be familiar with using their Facebook credentials to log-in to other sites, saving the hassle of remembering and entering many passwords.

The Microsoft HealthVault platform supports the idea, because it provides a service comprising of three main elements: a common single set of credentials (user ID, password) for a connected service; a personal health record containing a subset of the patient health record, and connectivity to a range of devices that exist on the high street.

The personal health record can be shared with healthcare organisations, family members and so forth. While the connectivity means that trusts like University Hospitals Southampton can pick up the transmitted data, and use it for monitoring and decision support functions.

But we don’t have to have all of these functions to create one, consistent NHS identity. Just the federated identity would be a good thing, and could be provided in a number of ways; Open ID would be another alternative. There is also a digital initiative in the cabinet office which is quite interesting.

I would personally like to see us taking opportunities as they arise, and the creation of one, consistent NHS identity would in my view greatly transform the user experience of the NHS for the better. Would it also greatly assist all health care organisations in getting their patient services online?

Adrian Byrne

Adrian – Ade – Byrne is director of IM&T at University Hospital Southampton NHS Foundation Trust which, he says, has been working on its IT environment for 15 years.

On his LinkedIn profile, he says its aim is to “build an electronic patient record with full decision support, sharing data across disparate, so-called best of breed systems.” The trust is also developing a patient record and services, built on Microsoft HealthVault.