We’re prototyping a couple of other possible pharmacy service outcomes.
At the moment we’ve fleshed out and are building what’s effectively a NUMSAS compliant journey. But we know that the service landscape isn’t uniform. There’s variation in delivery between areas. So, what if the next step in the healthcare journey in a given area is a telephone clinical assessment service? Or simply a recommended pharmacy?
This variation makes working on a project like 111 online feel admirably flexible and utterly futile at the same time.
Flexibility
Why should the centre dictate how a service is delivered? The design of good services should not be dependent upon top down, centralised decisions. What, if anything, is intrinsically wrong with local variation in service delivery?
The interface of 111 online should be able to cope with how a particular need is met locally. This means being able to coherently display a variety of services which may use different channels of access, and require different (or zero) amounts of information from the user.
We’re edging towards this by designing:
- “one thing per page” subroutines for information gathering
- service views that emphasise the method of accessing a given service
Some of these design decisions are pragmatic. For example, our directory of services wasn’t originally built to be public facing. This means easily understood, well structured, granular service detail isn’t readily available.
Futility
If we’re at the mercy of the local delivery of services, why go to the trouble of attempting any design at all at the service level?
If variation in service delivery is a given, why even try to work out what a good user journey looks like? Shouldn’t we be sticking to the “answer some questions, get told what to do and goodbye” nature of 111?
Y tho
To be honest I struggle to find a solid position on whether or not we as a product team should deal with user journeys outside our product.
There’s an obvious disadvantage to do it, probably amply showcased by these weeknotes: sinking time and effort into journeys that won’t get built. Creating “service visions” that don’t get worked towards.
On the other hand, there’s the need to critique.
If you read the NUMSAS specification, the one-way nature of what’s being described is very striking. For example:
The referring service will either send an email to the pharmacy’s premises specific shared NHS mail account, or use another agreed secure messaging system, stating the details of the patient requesting an urgent supply of medicine or an appliance…
Patients will be given the pharmacy’s telephone number by the referring service and asked to call the pharmacy within 30 minutes.
NUMSAS Toolkit 2.1: Referral sent from NHS 111 or IUC CAS
Let’s think about that for a minute. Here’s this snippet of the journey (for any 111 channel) from the user’s point of view:
- give your personal contact details to 111 for a referral
- be told which pharmacy you’re being referred to
- get given that pharmacy’s phone number and told to phone them within 30 minutes
So, I’ve given you my details for referral, and now I have to phone the pharmacy? Not go there?
Where a pharmacy does not have the medicine or appliance in stock, a referral to another pharmacy should be suggested to the patient, and agreement obtained. Before the referral is made, the pharmacist should be confident that an emergency supply is both possible and in the best interest of the patient, bearing in mind that the receiving pharmacist will have to use their own professional judgement as to whether or not the requirements of the HMR are met.
NUMSAS Toolkit 2.10: Troubleshooting
So the reason I need to phone the pharmacy is to make sure they can help. If they can’t help, it now falls to them to help me.
Shouldn’t our service be doing this work? At the very least we could check if the place we’re sending you can actually help you? That might not be a digital service to begin with.
So going back to the question of whether it’s futile to consider user journeys in the round (as opposed to simply inside our product), there is one good reason.
What if we never get to build any well designed user journeys?
Being able to critique what we’ve been tasked to deliver, and having that critique heard, is important. Perhaps being heard is a step towards products being in the room where it happens.