An open standard for NHS patient letters

I’ve been spending some time recently with non-executive directors (NEDs) and lay members of our integrated care system (ICS). There are clearly many areas where we will need to develop interoperability and our joint working practices. It’s an exciting time and it’s great to be in discussions early on in the process.

One area where I think we could make a huge improvement to citizen experience is with a single open standard for NHS patient letters and communication. Let’s start by looking at some of the challenges.

User needs

Until January 2020, I was the next of kin and carer for my adopted uncle, Nigel. Nigel lived independently with some assistance. He had aspergers and, over the last five years, battled with agressive lymphoma. Due to a previous incident, Nigel had a fear of things coming through his letter box and as a result, never opened his post. He received a lot of post from the NHS, appointment letters, results, requests for follow up samples. Due to work, I would often be away during the week and would often help him with opening his post once a week or fortnight. This led to missed appointments, lack of time to organise patient transport (meaning I had to take time off work), lots of confusion and lots of stress. Most telephone booking lines weren’t open at weekends so I then had to wait more days to reorganise appointments. Missed appointment letters would then be delivered and cause huge anxiety for Nigel as he loved nurses and hated letting people down.

Or take my nan. Until last year, she lived independently and was incredibly fit for someone in their 90s. However, dementia meant that appointments and letters were really challenging and she’d quite often hide or lose important letters before my mum could get to them. Mum tried to access different systems for proxy carer access, but not seemed easy or reliable. Connections with single services were better but there was disparity across the wider system. Now nan is in a care home, the carers can look after a lot of this, but it’s still important for my mum to be informed and kept up to date without that burden being placed on the care home.

Paper letters through the post really don’t work for me either. Sure, I can open a letter and reliable action it, but it’s not how my life works. Pretty much everything else arrives to my smart phone and automatically gets added to my calendar. Which more importantly means it is automatically added to my wife’s calendar so she can remind me when I have an appointment! Often I can now book appointments online, via the NHS app or over the phone. By the time the letter arrives 3 days later, I’ve already manually entered the details into my calendar and the letter serves no purpose other than to fill our recycling bag.

I’d love to imagine that the sending of all these patient letters is automated and doesn’t take hours of staff time. However, the letters that arrive with stamps stuck to them, instead of even being franked, suggests that in some places posting letters is a manual and labour intensive job. Time that could be better spent on the phone supporting patients. In 2019, it was reported that missed GP appointments alone were costing the NHS £216million a year. Then there’s the huge costs of printing and posting letters.

1. Patient contact needs to be sent in a suitable format for the recipient – you can request information is resent in large format
2. Patient contact needs to have reliable proxy options and may need to be sent in multiple formats
3. Patient contact needs to respect the preferneces of the recipient with regards to medium, digital or physical
4. Patient contact needs to be timely, arriving as soon as possible
5. Patient contact needs to be actionable when it is received, no closed phone lines and dead ends – we could also remove conflicting appointments so some of this isn’t necessary
6. Patient contact needs to be qucik and easy for staff to send, it should not tie people up and be a drain on resources

A system wide view

When you look across the ICS patch, there are more organisations who need to contact citizens. Some will likely conflict, hospital appointments when social care are visiting. Fire safety checks when you’re having your vaccine. There’s more opportunity to miss appointments, waste money and create a worse experience for people.

I think there is a greater opportunity too. If we can solve this problem once, we can use this everywhere. And if we have good adoption, we can really start to do some interesting stuff.

A possible solution to patient contact

One solution was trialled in 2018 with DrDoctor used in 10 hospitals. I’d love to see the outcomes and feedback from that if anyone can signpost me. I think more can be done at a system level however.

The Gov Notify common component from the Government Digital Service (GDS) has sent 2.37billion notifications since the service launched and is used by over 4000 services. The NHS can now make use of the Gov Notify system and it has increibly competative pricing too. Over 70 NHS organisations are already making use of this service. But why not more?

What if we had an open standard for generating patient messages. An open standard that could be adopted by councils, GPs, NHS providers, charities and other services. What if as an ICS, we had a central point to process all these messages? You might argue that Gov Notify already makes it very easy for services to send messages, and you’d be right, but we’re yet to get to the best bit.

If a central solution was established at an ICS level, we can easily start to migrate services onto it. It doesn’t need to be big bang and it doesn’t need a big rewrite or for anyone to adopt a particular computer system. Heck, Notify will even allow you to upload PDFs from your mail merged Word document and send those for you, it can really work with any local process. If all our organisations send the messages according to a standard, with a standard patient identifier we could start to spot conflicts before the patient has to deal with them. This wouldn’t need to share a lot of data or divulge the details of appointments but if the system spotted that two appointments had the same time slot, it could alert one or both organisations or departments and ask them to reschedule before being sent. This instantly removes appointments that are missed due to conflicts, removes the need for patients to rearrange appointments they would never be able to make, removes the need for someone to answer the phone and rearrange the appointment and removes a wasted letter, envelope and stamp.

Respecting preferences

Gov Notify can send SMS, email and letters. So I could register my contact preference once with the central system and then all services would send my messages along my preferred channel. So if I want email, I get email, if I want post, I get post. You could even have both. And we could throw in automatic text message follow up for good measure.

We could allow a proxy preferenece too. So Nigel or my nan get their letter and me and my mum receive a copy by email. Or if patients don’t want all the details shared, I could just get a message “Hi Chris, Nigel has been sent a letter from Oncoloy”. At least I then know to check and talk to him about it.

Gov Notify has a simple API to retrieve a PDF copy of all messages sent from it. So these could easily be archived and linked back to patient records. Imagine too if this archive was avaialble through the NHS app too? I could see a full copy of all my correspondence from any health or care organisation in one single place that lives in my pocket. How many people with long term conditions currently carry ringbinders full of paperwork to and from hospital so they have all the information they need? I know Nigel used to.

I suspect this alone is worth doing. It allows services to take advantages of economies of scale and it improves patient experience.

Does it meet the NHS Service Standard?

Given we’re thinking about a new digital service, how does this stack up against the service standard?

1. Understand users and their needs in the context of health and care – we’ve understood the needs of our users here. We’ve looked at health and we’ll come on to including care too.
2. Work towards solving a whole problem for users – by moving from a single service to a system perspective, I think we’re demonstraiting that we’re thinking about the whole user journey and we’re influencing a wider solution which is further developed below.
3. Provide a joined up experience across all channels – we’re linking several channels of communication from “health and care” and providing a single, simple stream of communication to the citizen.
4. Make the service simple to use – this solution requires very little in the way of changes for the teams who implement it and simplifies a lot of things for citizens as their journey has less friction in it and less reason to need to make calls and rearrange appointments.
5. Make sure everyone can use the service – this works for every, whatever your contact preference, you’ll still get the communications you need.
6. Create a team that includes multidisciplinary skills and perspectives – it would be good to road test this out with more people and we’d certainly want a larger team to work this up into production.
7. Use agile ways of working – this really lends itself well to creating a minimum viable product for testing and then iteratively improving and rolling out the solution. There’s no big go live date, no huge list of dependencies.
8. Iterate and improve frequently – I’ve already shown how we can start small and iterate quickly with this. Below, I explore more ways we could iterate and improve.
9. Respect and protect users’ confidentiality and privacy – there is very little data that needs to be shared here and very few people who actually need access to the system. Clearly we need to ensure it is secure and later on, there’s consideration needed for automated decision making.
10. Define what success looks like and be open about how your service is performing – Gov Notify has a very clear stats page of how many messages have been processed and it would be fairly easy to report on key performance indicators like reduction in missed appointments, how many clashes had been averted and what the postal cost savings were. We’d need buy in and reporting commitment from across the ICS to enable this.
11. Choose the right tools and technology – by using common components and open standards, it isn’t going to be too difficult to ensure we have the right tools for this project. So long as the service has an open API that can be called from the major programming languages and systems, there’s nothing too technically difficult here.
12. Make new source code open – I’m sharing my thoughts and thinking openly here and there would be so much benefit from developing this in the open and sharing as open source code so that all the other ICSs could make use of the same solution and contribute back to the overall product.
13. Use and contribute to open standards, common components and patterns – we’d utilise a common component and potentially develop another common component for messaging. I think an open standard for message formats and processing to allow easy comparisons and some of the more advanced stuff below would be really helpful. There’s possibly a standard out there already, let me know in the comments if you’re aware of one.
14. Operate a reliable service – Gov Notify seems to be pretty rock solid and with some careful design decisions, it would be easy to ensure jobs were queued and processed in a resilient way that enabled fault tolerance and checks to be performed.
15. Support a culture of care – showing we care not just about what we’re doing for and with patients but how we get them to meet with us and look after them before and after appointments seems a good way to meet this point. I think it also shows care for staff and for carers in supporting them and respecting their time.
16. Make your service clinically safe – this is probably more relevent with some of the things I come on to below around automated decision making and would need to be worked on apprpriately before features were implemented.
17. Make your service interoperable – the whole premise of this project is interoperability. Tick!

Making patient contact even smarter

So we now have a single point within our ICS that handles all the contact to our citizens and we’ve started to reduce waste and improve experience. We’ve got improved access to a patient’s own data and some useful opportunitieis for timely reminders. Let’s take this further and see how much value we can add.

Connect up the third sector

When a user registers their contact preference, why don’t we let them select other services that they access? Some kind of approved partners list. In time, maybe we can automate this but that seems like we’d need to bring social care and the third sector into the summary care record? So Nigel tells the message service that he has a carer visit twice a day from a charity, that he receives meals on wheels and that he requires patient transport.

So now when an appointment contact is issued, the central system can do the following without sharing a huge amount of data or need to integrated with third party systems:

• Email the home care charity and ask them to rearrange the carer for that day
• Email the meals on wheels service and ask them to deliver his meal at tea time not lunchtime
• Email the patient transport company and ask them to call him and arrange a pickup – with permission, we could share the location, department and times this is required so Nigel doesn’t have to remember or worry about getting the details right.

This needs a little thinking through about data sharing and security, but very little additional code would need to be developed to enable this and it wouldn’t prevent anyone from continuing to access services if they didn’t register their preferences, they would just continue like usual. However, this then reduces wasted carer visits, wasted meals and further reduces missed appointments from where transport was an issue. This is starting to feel really joined up.

Speak my language

With a light weight preference set, as well as methods of contact, we could store language and additional format preferences too. Almost every letter I receive says “If you need this information in large print, phone X”. If we have the user’s preference and requirements stored centrally and funnel all communication through that point, we can send the right information, in the right language, in the right format, first time, every time. Braille, large print, non English, easy. And we just build this once and the whole system benefits.

Hook up Amazon Polly and we could produce audio files that we text to people so they can listen to the information they need. We’d need to think carefully about medical terminology and information, but there are aways around this with custom word sets. AWS Polly can also handle translation and alternate language speach too. It’s very cost effective and processes in milliseconds. This feels like we’re starting to address personalised care too.

Automatic scheduling

This one takes a bit more integration, development and co-operation, but could potentially have a huge impact on the amount of visits a service user has to make to different locations. From where we live, it’s about a 45 minute drive to the Urology Department, over 90 minutes at rush hour. Factor in parking and leaving wriggle room and a round trip for a 5 minute checkup can take 2.5 – 3 hours easily.

Nigel regularly needed to see a radiologist, have a fluid drain and be seen by a dermatologist. Most of these appointments were reasonably regular but didn’t need to be precise dates. What if, instead of booking exact appointment times for each service, the clincians could request an appointment within a specified time window? The message system could then collate all this information, ‘in 2-3 weeks Nigel needs to go site A for radiology’, ‘in 3-4 weeks Nigel needs to go to site A for outpatients’, ‘within the next 6 months we need a discharge meeting in dermatology’. It then seems like a single visit to site A in 3 weeks time for Nigel could be a really productive trip. It’s either a single period off work for me, or a single round trip for patient transport.

Clearly this requires a lot of complicated access into all kinds of scheduling systems and processes but I think this could really improve the lives of people with complex care needs and could substantial reduce the CO2 emmissions from our health and care system.

Community nursing and acute care working together

Travel to our local acute sites, particularly at rush hour and shift changes is slow, frustrating and stressful – especially if you rely on public transport. This impacts staff even more than patients. Imagine a two hour drive before your 12 hour shift, every single day. You might think as the NHS, there isn’t much we can do about this. We can’t build roads, we can’t run more buses and we can’t easily relocate our services.

But what if we radically reduced the number of patients who need to travel to acute sites between 8 am and 10 am every day? During the pandemic, there has been an explosion in the use of telemedicine and remote consultations. What if we made a significant number of appointments before 10am remote? This would mean less patients and potentially some staff joining the rush hour. The difference of school traffic being off the roads at half term is staggering so even small changes in total traffic volume can improve things for everyone.

Some people won’t be able to access this however. But if we know who needs a community nurse or integrated care team visit before 10 am and who also needs a remote consultation at a similar time, our system could start to make intelligent pairings. Imagine we send a digitally enabled nurse to see Nigel. They use their smart devices with an integrated camera to video call the radiogist when they make their routine visit. They can answer medical questions more actually than Nigel could, take observations and move the camera to look at a focus area for example. 5 minutes extra for our community nurse, but 3 hours saved more Nigel. 2 patient transport trips saved. 1 less vehicle on the road. We can then schedule patients to arrive and be seen at the hospital sites while the community nurses move to their next patient and schedule another video call for a suitable time.

This doesn’t necessarily need to just be community nursing and acute. GPs, social workers or carers could be trained up and become digitally enabled visitors to enable remote appointments. I saw a few years ago that a Fire Service were performing wellbeing checks and reporting back to GPs and social care about a person when they had made a home safety visit. The Fire Service were visiting anyway so a few extra minutes to check that the person was washed, had food and was moving around ok hardly had any impact on the Fire Service, but made a huge difference to enabling social care to prioritise their workload. Why not get your smoke alarms tested while you speak to a clincian on the fire fighter’s iPad?

An opportunity for suppliers

With an open standard for how messages should be sent into the central messaging service, third party suppliers and software vendors could easily add functionality to their products to enable interoperability. If we make the main system open source and encourage wide adoption across all the ICSs, there will be a big incentive for suppliers to get involved and support the project. So over time, your EHR, scheduling system, patient management systems and other apps could start to offer this functionality out of the box and increase opportunities and benefits.

In conclusion

This is a bit of a brain dump. There may be other people already doing this, I’d love to find out what’s going on. Hopefully by thinking out loud and working in the open, we can progress ideas like this, improve them and make them a reality to deliver better outcomes for our friends and families. I can’t do this on my own, but maybe someone else hasn’t had the idea and we just needed the ball to start rolling?

Some of this could make a difference within a single organisation, especially one with many departments. But I think the real benefits are when we start addressing these issues at a local system level. Natioanlly I think this is too big. Locally there are opportunities to address specific needs, transport might not be a major factor in your area. We could also connect to work around local care records.

Where there needs to be a national element I think is developing the core open standards for how we connect messages together and an open source solution that delivers the basic functionality, integrates with GDS common components and enables local extensibility.

Share your thoughts and ideas in the comments below and let’s see how we could take small steps to make a huge difference.