Let’s talk about sex*

This is a picture of my Dad and I on their 60th birthday. We went to the ballet. My Dad recently turned 65 and last week they received their first dose of the Coronavirus vaccination.

I recently worked with a team at NHS Digital to help deliver the ‘Book a coronavirus vaccination’ service. A booking service accessed via the NHS website that allows you to book your appointment once you’ve received your invitation.

The trans community had already experienced difficulties ordering coronavirus tests, with some councils setting up alternative provision for trans people. It was therefore important to me that the vaccination service tackled these issues from the start. My Dad is trans and I really wanted them to be able to use the service I contributed to building to book their vaccination appointment without any issues.

I found out early on that while there was no clinical or monitoring need for data on gender, the service was to require it to match people’s vaccination information to their GP record. I knew immediately that this would potentially exclude members of the trans community. We therefor set about trying to find a solution that would remove the need to ask for gender information, or if absolutely necessary to ask, do so in the most inclusive way possible.

While we didn’t quite make the changes required to ensure the question wasn’t included in the first release back in January, we’ve come a long way. Three weeks ago gender was removed from the matching API and today the question was removed from the vaccination service, less than three months after launch.

Why was this question included in the first place?

The ‘Book a coronavirus vaccination’ service is built on top of another NHS Digital provided service; the Personal Demographic Service, or PDS.

PDS helps healthcare professionals to identify patients and match them to their health records. It also allows them to contact and communicate with patients.

In order for somebody to access our service we needed to verify their identity using a check against PDS.

Currently PDS holds four data attributes: Male, female, unspecified and unknown. This data is labelled ‘gender’.

This is problematic for a number of reasons:

  1. While this data is labelled ‘gender’ it is often equated with sex, leading to mixed information in this data set
  2. Not everybody identifies as a binary gender, this therefore excludes non-binary people and other genders
  3. The API was built to allow access to PDS. It included gender as a mandatory field however not every service that needs to connect to PDS will be justified in collecting this data

Building inclusive front end services on top of older infrastructure services is challenging.

Finding a solution

I hadn’t worked with technical architects until I came to NHS Digital six months ago. Throughout this project, our Technical Architect, and I worked closely but never more so that when this challenge arose.

Other services had faced this problem before. They worked around it by calling the API 4 times (once with each gender option) until they found a match, meaning they could avoid asking the question. Andrew Duckworth wrote about this here. As our service was set to be used by a large percentage of the population, this was deemed to be a performance risk.

So we set to work. Design exploring how we could ask the question in the most inclusive way possible and technical architecture helping us figure out how we could use the API without generating a performance risk.

This was clearly a problem others had faced before however it’s difficult to document guidance because there is no one right way to do this. Different use cases will lead to different solutions. For example, asking for monitoring purposes vs asking for identity verification would lead to differing approaches.

With the census now live, guidance is starting to be published. The ONS now has a published standard. Scottish Government have also done extensive research and are moving towards their own guidance through the establishment of a working group. This is a start, however there is still much to do.

We saw this in the news last week when the ONS were forced by the high court to amend accompanying guidance on the sex question. This had been produced to say that people could use the sex listed on their legal documents (passport or drivers licence), however this has now been changed as a result of the court decision so that trans people are required to answer with the sex on their birth certificate. This therefore excludes trans people who have not been through the arduous process of acquiring a gender recognition certificate, which is the only way trans people can change their birth certificate.

Regardless of what guidance is published on how to ask questions, it would still struggle to help people designing with specific technical constraints.

The solution we came up with was a huge team effort. We worked with NHS England’s LGBT Health Team, we consulted with the team who designed and ran the GP Patient survey and we drew on years of expertise within our own content community. We needed technical architects to help us understand how to work with the API, developers to help us understand how this last minute addition fitted within the context of the wider service, content designers to get the words exactly right and user researchers to test our designs with the trans and non-binary communities.

This was the point when I really understood how important it is that designers lean into understanding how a service functions technically. This solution relies on being able to do multiple API calls on the last three options. Without this function a designer would not have been able to deliver a viable solution.

What was most heartening was the testing we did with the trans and non-binary communities. Seeing people see themselves in forms they are so used to being excluded from was all the evidence we needed, not just for the implementation of this screen but to make the case for wider change.

Pushing for wider change

While I’m proud of the solution the team implemented, this question was unnecessary. It needed to be removed and the API changed to ensure no other service had to face this problem again.

Working through this wider challenge took persistence and resilience. While I left the programme at Christmas I knew I needed to keep pushing this for it to happen. I think what worked in the end was a combination of spring boarding off the fact this was a high profile service, escalation to people new in post and sheer bloody mindedness. I realised afterwards what kept me going was the personal connection I had to the subject. When you’re fuelled by something that means so much to you, your body finds extra energy somehow.

So I kept going.

Getting to where we are today meant getting work prioritised on two different backlogs during a pandemic when there is always ‘another urgent thing’. I had to help teams to understand why prioritising inclusion was the right thing to do. This was easier with the team I already had a working relationship with.

Thankfully the work has now been done to remove the question from the booking service but more importantly gender has been removed from the API. This means no service connecting to PDS for matching purposes needs to ask this question. This was a real win and I’m proud of everyone who contributed.

But there is still more to do

There is still an underlying problem that will continue to make it challenging to design inclusive services.

It’s clear that in 2021 how we ask this question is important, and the inclusion of marginalised groups is paramount. If we don’t include categories that acknowledge and affirm trans people’s existence, we will continue to exclude a proportion of society. A group of people who continue to face discrimination on a daily basis and experience some of the most significant health inequalities.

I have no doubt that this is only the tip of the iceberg when it comes to technical infrastructure that is holding us back from delivering inclusive services. There are people across government doing the best they can to plaster over the cracks but when we add the ‘why are we asking this’ reveal, we can’t write “because our database only holds two fields”. So what do we write instead?

What if we took a user centred approach to redesigning these central databases that sit at the heart of so many government services?

And in the meantime, if my Dad has to rebook their second dose for some reason I’m grateful this bit of their experience will be improved because of the work we’ve done.

*Credit for the title of this piece goes to the wonderful Nancy Willacy who always has a way with words.

Designing services that work for people. Design Lead @nhsdigital. Director at Aqua Garden. Previously @wearesnook @wearewithyou She/her.