Anyone who has been anywhere near the UK trans & non-binary community will know that the Gender Identity Clinic system is a consistent sore point, being as it is the only way for most people in the UK to access any sort of medical transition, should they wish to.  It’s woefully underfunded, slow and clunky.  Things may be improving in some areas, but demand is consistently rising and the apparatus is creaking under the weight.

We’re often told that this system is under review, but what does that mean?  Review is all very well, but without action, review is pointless.  As someone who has a background in Service Management, albeit mainly in the sphere of IT services rather than clinical services, I’ve attempted to have a look at the system, and what could be improved, through the lens of the typical tools & techniques I’d use in my day-to-day.

Tools of the trade

Firstly, a quick background.  In IT Service Management, we tend to talk a lot about something called ITIL.  ITIL is basically a set of guidelines we can use to design, build and operate good IT services.  Of course, nobody should see it as prescriptive, and so I’ve just used it as a base to put together some ideas.  ITIL talks about two key principles called Utility & Warranty.  I won’t go into detail here, but in essence Utility talks about whether the service does what it is intended to do, and Warranty is about how we make it do that; whether the service is reliable, usable and accessible, when it needs to be, and by whom it needs to be accessed by.  Thus, I’ll stick to talking about Warranty, as the Utility is more about the clinical side of things, which I’m not qualified to speak about.

In the context of our Gender Identity Clinics, I think Warranty can be mostly comprised of the following, which I’ve delightfully shoehorned into an appropriate acronym, C.A.R.E.!  These will be the themes that will probably recur throughout this article.

  • Consistency – how can we make sure that the service offered is consistent? This doesn’t mean one size fits all – it means that the system needs to be fundamentally fair, and that the same services work in the same way where possible. There are benefits here in terms of cost, simplicity/ease of learning, flexibility and navigability.
  • Accessibility – how can we make accessing the system more effective, taking into account different needs.
  • Reliability – how can we reduce failures in the system.
  • Efficiency – how can we make the system work more quickly.

Do the right thing

ITIL wants us to design our services around the requirements of the end users.  As such, we need to take a service user-focussed view.  This means we need to factor in that different service users have different needs.  However, we want to cater to those needs in as standard a way as possible.  This has a myriad of benefits:

  • Fairness (if two similar service users want the same service, they should get the same service – it is unfair to arbitrarily give different levels of service for the same need)
  • Speed & Efficiency (It is easier and quicker for service providers to offer standard services. It means admin staff and clinical staff do not have to spend as much time navigating different pathways or stage gates. As a general rule, the more familiar you are with a task, the quicker you will complete it, and with fewer errors)
  • Cost (It is obviously more cost effective to offer standard services. It means we can access the economies of scale, as well as the reduced costs associated with simplified services.

Service Management is all about providing the RIGHT level of service at the RIGHT cost.  Note, this does not say BEST or CHEAPEST.  It’s tempting to think of these things in terms of the ‘best possible service at the lowest possible cost’, but that’s a false dichotomy.  Somewhere along the lines there are decisions to be made about priorities, and low quality doesn’t necessarily mean low cost, and neither does a high cost guarantee a high quality of service.  It’s about whatever it right for our customer, in this case the service user.  An NHS service should, I would have thought, be about providing value for money.  We don’t need the white gloves treatment here.

I’ll zoom in on a few key areas that are pain points we hear a lot about, and that I think we can influence.  Also, crucially, I’ve factored in that we have no money to play with here, so all of this will be focussed on saving money, providing a better service for the same cost, or at least a zero net cost:

  • Service User Interaction
  • Admin
  • Reduction of error and service failures
  • Measuring Usage & Success

ITIL has processes which help us with all of these.  Specifically we’ll be looking a lot at the Service Operations space (there is, literally, a book on this) and Service Level Management.

How’s my CAREing?

I want to start with the last one – measurements.  This might seem an unsexy place to start, but this is a subject which is criminally underappreciated and misunderstood.  You can’t know if something is working unless you can effectively measure it, and you can’t improve something if you don’t know how you’ll measure the improvement.  If you don’t believe me, go and ask your boss for some money to implement your little pet improvement project.  Let me know what they ask for!  Also – and this really takes some cognitive gymnastics – reporting that everything is OK is useless!  We have to design our measure based on what we want the service to do, NOT on what we think it is capable of.  If our customer needs something in 5 days, and our service isn’t capable of delivering it in less than 7, we don’t set our service level at 7 days just because it’s the best we can do!  We set it at 5, and we work out what we need to change.  It might be that this means we’re doomed to scorecards with lots of red on them for a while, but that’s the only way we’ll get the focus needed to improve.  It also means we get a really accurate picture of the demand for our service, which helps us make good decisions about capacity etc. if and when the opportunity to add to, or redeploy, our resources arises.  ITIL has a process for all of this, and it’s called Service Level Management.

So, what are my recommendations here?  Well, let’s set a national set of measures for the service, and base them on clinically recommended timescales for service delivery.  We can base this on evidence of positive outcomes after certain periods of time.  The two absolutely crucial elements of this are:

  1. It absolutely has to be standard across the country.  It doesn’t matter that we have different ways of delivering services at present, human beings are fundamentally the same in London as they are in Leeds (now now, calm down) and so we can’t justify different service levels.  We should keep England, Scotland, Wales & NI in line too, even if we could argue that the customer is different (different NHS commissioning bodies).
  2. We must set these service levels from a Service User’s perspective – remember, we’re user-focussed here?  This means that wait times are measured on how the Service User experiences them, not on any admin gates at the provider end.  The end user doesn’t care if you have to fill out form UT773b and wait for Hugo to get back from holiday before making a referral – they’ve been waiting since their last appointment.  We call this end-to-end service management and it’s absolutely key to making this work.  We don’t want our users to have to worry about the internal machinations of our administrative process.  One of the big problems we see at the moment is that services work at completely different speeds dependent on how clued up and pushy the Service User is – this typically means that people with certain privileges get better treatment, and it’s fundamentally unfair (Yes, yes, I see you at the back there, vibrating with rage, the veins in your temples near to explosion over that last point.  We’ll come back to that later).

Metrics and targets and feedback, oh my

So, we’ve worked out how to measure our services, but what do we do with this?  Well, we report on how all our services are doing against these metrics, and we sit down and review them periodically.  We call this a Service Review! Once we’ve got over the initial shock of seeing all those failed metrics, we look at what’s going wrong and we build a plan to address the issues.  This might contain all sorts of fanciful ideas, but I did say we’ll focus on the realistic (i.e. pretty much free) ones, so that’s what we’ll do.  So, what sort of things might this contain?  Let’s go back to my original list…

  • Service User Interaction
  • Admin
  • Reduction of error and service failures

Now, depending on whether you’ve used a GIC (and if so, which one), you’ll have different ideas on the order in which these should be tackled.  Actually, I think they’re all co-dependent and so we’ll look at them as a single piece.

Because we have poor admin, we make errors which means we have increased queries from Service Users, which we handle poorly so we get further errors which means Service Users have to contact us more often and…well, you get the idea.  It’d be easy to say that we need to spend a load of money on improving our user interactions, and invest in a ton of frontline staff and expensive Customer Relationship Management software, but we really don’t.  We just need to give them fewer reasons to contact us, and make it simpler and more efficient when they do.

I think we can all agree on something

Let’s think about admin for a moment.  A lot of admin is quite repetitive, but we also see a lot of subtle variation, and detail is important.  We usually have low paid, overworked staff, and thus we have a high rate of turnover.  This is the ideal breeding ground for mistakes.  Thankfully, a lot of very clever people have done a lot of research into making processes like this work, because it turns out that an awful lot of organisations have an awful lot of repetitive processes, and making them work efficiently saves them an awful lot of money.  It’s at this point that management consultants like to start talking about production lines and Toyota and Kaizen and Lean and Six Sigma, but basically all we need to know is that defined, efficient, standard, managed and repeatable are all good things.

What could the recommendations here be, then?

  1. Define our process. Get the right people in a room, make a big chart, put it on a wall, understand & document all the required inputs & outputs at each point and who needs them, and what they do with them.
  2. Standardise our process. This is where we take a picture of the big chart & we send it to all the GICs and say “Do it this way now”. Of course this might take some persuasion & some training, but since we involved all the right people in step 1, it shouldn’t be too hard.
  3. Where there are services made up of elements delivered by different people, we have to document the prerequisites for each one, and agree the way in which workload is managed so that it is standard & consistent. For example, if a service provider is receiving referrals from different areas of the country (say, for a specific surgical speciality), we need to design the process so that we manage those referrals in a fair and consistent way, so that we don’t have regional variation.

Hold on, isn’t this all going to take a lot of time and effort?  Well, yes.  But the trade-off is that we save loads of effort later on, because we won’t be reworking & sorting out exceptions all the time, because we got it Right First Time!  Remember that bit I said I’d come back to, about services operating at different speeds for different people?  Well, here’s where this comes in.  If we have a robust process and we know where everybody is in that system, when there’s a clinical need for the process to be circumvented or to move more slowly, we can do that.  Similarly if something goes wrong, we can cope with that without losing that person’s details and dropping them into a black hole in the system.  Pleasingly, Pushy McPusherson who phones up every day to try and get their referral done more quickly won’t jump ahead of anyone who has been waiting longer in the queue, because we know where everyone is and the order in which they’re in, and we know the requirements for any deviation from that pathway.  Even more pleasingly, Quiety McShy won’t lose out because they didn’t call their chums in the national papers the moment their wait tipped into the 19th week.

Means of contact

By now, that Service User interaction problem we had is reduced, because we’ve eliminated some of the key pain points.  However we still have a big capacity issue, and so people are still going to be trying to find out what’s going on with their referral, and of course any service is going to generate all sorts of queries and requests along the way.  Again, our Service Management toolkit gives us a few ideas as to how we can address this.  In ITIL we’d call this a Service Desk. In this context I’m going to talk about Request Management (I want something) & Incident Management (something has gone wrong).

If someone contacts us, their contact probably fits into one of those two categories.  A basic premise of Service Desk Management is that the closer to the Service User we can fulfil the request or fix the problem, the cheaper and quicker it is.  This is where I’d usually like to propose self-service systems so that people can update their own contact details if they change address, or look at their place in the queue on a web portal rather than phone us up, but we don’t have any money for any of that.  Therefore all we can do is be as efficient as possible.  If you open the book of Service Desk efficiency, lesson number one is that The Telephone Is Very Expensive.  Having people spending their time on the phone is therefore to be avoided, so, given that our only other option is email, we should try to use that (assuming we can’t build a web portal or online chat facility).  With email, we can use standard response templates to save time, we can avoid errors caused by mishearing people, we can redirect complex queries to a more appropriate person.  We can even auto-reply (for example, if we put the current waiting time in an auto-reply, it will probably answer some of the queries we receive before we’ve even read the email).  Of course, we can’t do everything via email, but having both options will take the pressure off the phone, and it also gives us accessibility options so that those who can’t use the phone can use email, and vice versa.

A final point on that word “standardisation”, by the way.  If we have all our GICs using a standard process, we can be even more efficient by centralising a lot of the Service User contact.  A great way of getting work done more quickly is to direct it to people with the tools & training to complete it quickly, and have them complete a lot of similar requests in batches, rather than constantly flitting from one activity type to another.

In conclusion

Now that we’ve done all this, what results can we expect?  Let’s be absolutely clear, no amount of efficiency and standardisation will make up for a system which lacks the requisite capacity; however, we can ensure that we make the best use of what we have.  This also means delivering a fair service to all users.  Finally, we can really measure how our service is being used so that we can make the best possible case for any changes that we do decide to make.

by Natalie Washington (@transsomething)

To get involved, please contact us