We spoke with our Head of Engineering Ben Edrich about the challenges of working with the NHS, the value of keeping systems healthy, and how we can see ‘the wood for the trees’.
“If you look at it from an operations point of view, rather than a development point of view, you can make complex systems easier by doing things in the simplest way possible.”
Ben Edrich, Head of Engineering
Can you tell us a bit more about your background before joining Feedback Medical?
I initially pursued jobs as a web designer – I wrote my first website in 1996 – but instead found myself in an operations role for a company called Elsevier Science who ran websites in the biomedical sphere; these were essentially online versions of their publications including The Lancet and Current Biology.
I then moved to a financial start up, running websites for IFAs to look after the funds of their customers, where I was for around 15 years in operations and architecture – that organisation grew substantially during my time there, going from around £1 million under management when I started to around £85 billion under management when I left.
From there I moved into development; creating a website servicing horse breeders and that industry, which led me to a role at CR Bard (a spin off of healthcare firm Beckton Dickinson) who had two applications that focused on reducing costs in the NHS and making things easier for patients – which is what I’ve followed through in my role at Feedback Medical
As Head of Engineering, what does your role within Feedback Medical entail?
I initially joined the company as a lead developer, focusing on working on our integrations with the NHS.
For Bleepa, our focus is on the patient and providing them to access to the NHS as a whole rather than focusing on what any one individual hospital does.
One of the applications we’ve been integrating with is called PDS (Personal Demographic Service), which stores information about you as a patient, not your clinical information but information such as where you live, your date of birth, your preferred pharmacy, etc.
When you’re referred into a hospital all the information around you as a patient comes from that referral – and that can be different depending on how that’s been inputted – whether you call yourself Ben or Benjamin when you registered, for example.
It’s important to work with resources centrally available in the NHS to get a single source of truth that contains as much information about that patient as possible; you need to know you’re doing the right thing in terms of following the guidelines from the NHS rather than doing something different each time.
Given my background, I identified a gap in terms of us running systems and ensuring that those systems are healthy, that we know how they behave. My role has evolved to Head of Engineering, as what we’re looking to do is create a function within the company that lets us know what’s going on with all of our systems, which is going to be even more important as we scale and expand.
What would you say are the challenges of developing systems for customers like the NHS?
The challenges really come from dealing with the complexity of progressing and pushing through integrations across systems to improve things for patients whilst doing things properly and putting patient safety first.
Within the NHS there are so many use cases and so many ways of doing things, and the only way to manage that is through standards, which is required – you can’t have lots of different people trying to do the same things in different ways.
That’s not an unusual thing in programming and coding – it’s a good thing.
Everyone has their reason for wanting a particular aspect incorporated into those standards to suit their use case, which means the NHS has the difficult job of trying to keep everyone happy, or most people happy in delivering standards that everyone can use.
What this means is that any application that wants to connect with the NHS will have to follow a process to do so, which usually depends on a SCAL – that’s a Supplier Conformance Assessment List; the list of things you must prove to say ‘my application is worthy of connecting to your systems’. That can be a long and drawn out process and required working with teams in the NHS who are incredibly busy.
The actual connection to these systems isn’t necessarily that complex – that’s about making sure the application is secure, it’s assured and it does what’s expect of it – but as with any company working with the NHS, the issues you face are often around resourcing and unexpected complexities, such as shifts in national priorities.
The NHS might seem like a bit of a dinosaur in some areas but the people working on these systems are generally great, and the systems themselves are responsive – it is the process of implementing those integrations that can be challenging.
NHS standards are also constantly evolving – you might find that data instructions have moved on during the time you’ve been in development – throughout the process you have to think about the balance; what do you actually want to do yourself, what you’re doing to meet the needs of the NHS assurance team, but also your own customers.
That’s the benefit of the recent work we’ve done to integrate with NHS England’s electronic Referral Service (e-RS) and GP Connect – which is a way that clinicians can access a patient’s GP record. Whilst the process took that time to integrate and we were one of the first companies to implement this in some time – the result is that it strengthens the workflow we can offer with Bleepa.
Now clinicians can share details directly with GPs via Bleepa, rather than letters or email, which is much safter and quicker and still retains that ‘single source of truth’ in terms of the patient.
What do you see as the most important things that we need to make systems like ours happen?
If you look at it from an operations point of view, rather than a development point of view, you can make complex systems easier by doing things in the simplest way possible. This comes back to those NHS standards; having one approach for doing something.
For a scalable approach you have to be operating in the same way everywhere; as soon as you’ve made an exception, then that can create a vulnerability; all the systems will work apart from that one, and that’s the one that’s always going to go wrong.
So it’s about trying to apply the same approach as far as you possibly can; there’s always going to be some variations, but if you can standardise you can constantly improve and make things more usable, clearer and more transparent; in a way it’s literally about being able to see the wood for trees.
This allows you to remove any preventable incidents, by gathering information about your system and understanding trends within it – what’s going on, when the busiest times are, when users log in, etc. That allows you to make sure you have enough resources to handle it.
To get in front of incidents you need to have a standard framework; that way if you find a problem with one system you can plan for that to happen in another environment because you’ve built it same way there. If you’ve got 100 different systems doing 100 different things you can see how that becomes completely unmanageable.
What you want is an application that essentially does the same thing; there can be different functions and features from customer to customer, but the fundamental way it works should be same – which is what we do with Bleepa behind the scenes – and that helps us to understand how it works, how it’s not going to work, and how it could potentially be broken.
As an engineer, you must be a bit of a pessimist – you have to say: ‘that’s a great idea, what’s going to break?’
You need the visibility and understanding of your system so you can predict what’s going to happen and make sure your system has enough support to do what it needs to do. This is where it’s so exciting that we’ve recently recruited new members of the team who have experience in working with such systems.
They’re bringing new ideas and new ways of doing things with recommendations based on the best practice from colleagues who’ve got great up to date industry experience.
That means we’ve added experts in each pillar of the platform that compliment the overall experience – bringing in dedicated database expertise, dedicated engineering expertise, for example – we’ve improved the resilience of our team and improved our overall coverage of knowledge.
Read the previous entries in our staff expertise blog series:
- A conversation with Chief Financial Officer Emma Oswick
- A conversation with Integration and Support Engineer Debbie Mason
- A conversation with Daniel Measor, Deputy Director of External Affairs