Interoperability Saves Lives

This article was originally published at Interoperability Saves Lives (vix.digital) in 2019. It has been migrated here as VIX Digital will be shutting down after the acquisition by KRY/Livi.

--

Last weekend we attended UK Health Camp as gold sponsors. I ran a session called "Interoperability Saves Lives" with the aim of sharing some of the experiences I had when leading the development of the NHS 111 interoperability landscape and hearing about other great interoperability initiatives people had seen in practice.

As we discussed the work I had been involved in from NHS 111 it was apparent that there was a lot of value in what I was sharing and a question came about blogging, had I done any regarding this stuff? The answer was unfortunately no, but I did commit to writing some and sharing them.

As the service integrations are so wide and varied I need to split them into individual case studies. The first one is on Ambulance Dispatches.

A Case Study on Dispatching Ambulances

When I joined the Department of Health team in 2011 to be the country's Interoperability Subject Matter Expert, I had already embraced the service specification and what it aimed to do. One part stood out to me more than all others “Providers must have the ability to dispatch ambulances without delay”.

My initial thoughts, this was going to be a breeze, tell all the people to tell all computers to talk using standards, that would do it. Or so I thought.

You’re Going to Do What?

Ambulance Services, that’s right there is an s on the end, 13 of them at the time, they are simply the most loved service in the country, because when you need them, you really need them. The teams save lives, every single day, from the phones, in the vehicles, on the road, you name it they do it. I will never forget witnessing a 999 call where a baby was born at home, lifeless, blue, through the work of the team they instructed the mum to bring the baby to life and the cry of the baby still rings in my ears to this day. It was the most overwhelming emotional day at work in my life, I had tears streaming down my face, I do now just thinking about it again.

I had the privilege of speaking to every Ambulance Service to inform them that not only are they going to need to let a foreign organisation dispatch their most precious resources, but we were going to all do it in the same consistent manner using technology that didn’t exist yet. You can imagine the response, the risks were huge, but so were the rewards if we managed it properly. Here we are now, 7 years later with circa 12 million ambulances dispatched electronically using interoperability in every part of England.

Here is the playbook of how it happened from my perspective.

1. Put Some Controls in Place.

All providers were required to meet the service specification and a specific section referenced that compliance with a national interoperability specification that would be produced, must be adhered to, my job.

They needed to meet both specifications, assessments were done and if they failed they didn’t go live. It wasn’t easy and there were many challenges but the controls worked, in the same way spend controls at GDS are used as a mechanism to stop bad things happening. My job was to ensure that the technology wasn’t smoke and mirrors and worked properly from day 1. If you were a supplier who wanted to operate in this space then you would comply, or not be involved in the service.

Mandates are not big and not clever, I personally hate them if they end up closing markets and I did my best to ensure everything was as open and as fair as possible, everyone who expressed interest made it, thankfully. However the minimum requirement was the minimum.

A technical go/no go decision would be compiled into all the other areas of assessment clinical governance, operational service design, training, etc passes were needed across the entire service. It was a big decision and I had the backing to make it on the technology front.

2. Understanding the Problem You’re Trying to Solve.

The reason this requirement was in the specification is because if prior to NHS 111 if you called NHS Direct or an Out of Hours service and needed an ambulance, then in many cases you would be told to hang up immediately and call 999.

This could take minutes (2.5 was the average measured) for the patient to do this and get to a point where a vehicle was on its way to them. That is a long time if you are having a cardiac arrest, clinical colleagues informed me that things don’t look to great after 8 minutes.

There was also the risk that the patient never actually did call 999. Not a good outcome.

Those minutes matter, you need them on your side. It now takes a just a few seconds for an ambulance to be dispatched from NHS 111 without the patient having to do anything other than follow instructions to help them while the ambulance is being dispatched.

3. Understand the Existing Service.

It’s called user research now, I didn’t realise I was a researcher being a technical architect type, but I found myself in every ambulance service operating room in the country along with the operational service designer.

So much time was spent observing how call handlers, dispatchers, paramedics and the management teams ran such a critical service. I took notes, a lot of them, as did the rest of the team, we found the friction, drew diagrams and shared them with colleagues, we circulated them with everyone affected.

It didn't stop there, they were refined time and time again until they represented reality and the many unpredictable elements of the service. It was really hard work but we understood intimately what the people receiving these calls needed in order to act. So we built it exactly like this right? Wrong.

4. Build the Prototype

What is the minimum we could do to learn? Well we knew there would be some trust issues, I mean 999 staff go through some very rigorous training, how could an ambulance service feel assured bad things wouldn’t happen?

111 call handlers would receive very similar training to 999 call handlers and would be proficient in the same professional language. To be safe we had to design the technical architecture for failure, be prepared to ‘take the service offline’ in newspeak. A minimum dataset was created for when the technology failed, a secret number would be provided to the 111 call handlers and a verbal handover would occur without having to repeat all the questions and answers the patient had provided.

This was pretty cool, it was something we could use and test without building a single thing and that is exactly what happened. Small cohorts of calls were passed between the services in a verbal manner, closely monitored, lots of controls were in place to cover all scenarios and the patient received a service that met the design intent, dispatching ambulances without delay.

People began to trust it, and guess what, we learned a tonne that would not have made it into the technological build had we not done this. Special access code to get into the block of flats? That wouldn’t have been in. Scene safe to attend? Could have missed that too. How about the primary reason the patient thought they called? Nope, just the prognosis and some questions and answers.

There is nothing like seeing things in action in a low fidelity manner to understand the needs of the users. Seeing it work in this way was interoperability but instead of computers people were using telephones. Minutes were saved, lives, money, things that matter.

5. Build the Thing

It’s quite a surprise to me that I don’t have much to say in this section being the technical person designing something so critical, but to be honest it wasn’t the hard part. We designed some messages, thought about how they would interact, built some things and asked a lot of suppliers to build some things that matched our things. The key thing with interoperability it that it's not about technology, it's about workflow and working seamlessly as one for the benefit and safety of users.

The one thing I guess I can say here is that this section is why the majority of interoperability programmes fail, and will continue to fail. It’s not about FHIR, CDA, HL7 or any other standards. They all come with the same promise of solving the problems of the past, but it was never the standards that were the problem. Sure there are better ways of doing things and the above standards are important, but to be perfectly honest with you, we could have used CSV files over TCP and it would have worked.

The big problem is that, interoperability programs start with step 5 most of the time.

6. Test It in a Small Area

What could we possibly learn by testing? Well a lot as it happens. We learned that the way Java and Microsoft Web Services handled SOAP was different.

We found bugs that were safely handled as we dual ran with the ‘prototype’ handover process in place for good measure until we had sufficient data, scenarios and volume to feel assured the technology was fit for use. It wasn’t perfect, but was safe, it works and it saves lives and could be iterated.

There is nothing like testing in the real world, simulations are never like the real world, people test with perfect data and scenarios, rarely the edge cases that are very hard to imagine creep into testing.

7. Sell It

Hurray it works, if you build it they will come.

Unfortunately not, the next year of my life would be travelling the country, giving people access to my knowledge, helping them understand the whole technical design, give them time to be heard, learn and contribute where we had missed things.

I didn’t do much architecting this year, I was evangelising for the thing I had designed. Guess what though, after it had been running for a few weeks it didn’t take long for the benefits to speak for themselves and help me in my mission.

You see, ambulances need to attend within 8 minutes if a patient is thought to be having a cardiac arrest or other serious conditions requiring that level of response. The minute the phone rings the call is considered ‘connected’ and the clock starts ticking for the ambulance service they need to answer the call when they have someone available, identify the location first and set the vehicle off screaming down the road while they continue to ask questions and work out what is wrong, they need to meet the target for themselves and for the sake of the patient.

Sometimes though it doesn’t need that level of response and once that is determined the vehicle goes back into patrol mode and stops screaming down the road returning to patrol mode, that's why you see them do that. This highlights that there were savings to be made.

Let me walk this through with you:

• So, if a patient calls 111 and is determined to need an ambulance.
• They don’t have to call 999 and repeat themselves.
• They don’t have to add 2.5 minutes to their wait time.
• The message takes a few seconds to be sent and a positive acknowledgement sent back to the call handler.
• The outcome is already determined at this point.
• 999 Call handlers don’t have to answer a call, meaning the line is free for the next 999 caller.
• The most appropriate vehicle response is dispatched first time.
• Extra minutes for everyone, lives saved, £ saved, I would call that a win win.

Conclusion

It was the start of a brand new service that would evolve over time and still is doing to this day.

I learned so much and of course there are things I would do differently if I had to do it all again. But the result, that I would not change for anything. It’s the most important work of my life so far. I am so grateful to give it the years I did.

The key takeaway message is that interoperability is super hard. It’s not about messaging, it’s about trust and that trust has to be earned between the parties involved, you need a shared goal, someone empowered to make decisions and a lot of elbow grease by talented folks. There are so many people who contributed to this work to make it a success, I just had the privilege of leading the technical parts of it.