Blog > Perfecting patient privacy - 2 hour Agile challenge

I've a bit of time between jobs and wanted to keep my user centred design skills sharp so I set myself a challenge to see how far I could get with a Discovery and Alpha into the tricky issue of health data privacy in just 2 hours. The blog below details that story:

00:00 to 00:08

I've started with a blank folder and just this Markdown-based blog post to track my progress. Starts the timer.

Before I get going properly, I make a little plan of action for the first 30-45 mins (in which I'm hoping to get the Discovery completed). This basically goes into the three questions I always like to ask myself before I start prototyping.

  1. Who are my users?
    1. What are their demographics?
    2. What is their digital maturity and accessibility needs like?
    3. What are their beliefs and desires?
  2. What problem am I solving for them?
    1. What are the needs involved in this problem space (patient data privacy)?
    2. Where do these needs interact with current services?
    3. Which of these needs are most important to users?
  3. What product best fits these needs?
    1. What solutions fit best? (off the shelf / build from components)
    2. How will this solution integrate with existing services?

00:08 to 00:46

With my plan created I start to research in earnest - creating very rough notes. The WiFi in this Starbucks is a bit rubbish so I switch to my phone.

I've decided I'm going to scope this to England so I can use NHS data / ONS data. Given time constraints I also quickly decide that as Wales has a population of about 3m (vs 56m for England), I can treat English and Welsh data as "good enough" for England.

This is the point where, using Google (I find ChatGPT tools slow me down), I end up down a rabbit hole of public demographic and opinion data.

00:46 to 00:57

Lots of useful information found which will inform the next stage of doing some synthesis. This has revealed several pain points which this 2-hour product could address:

  • Users find the current "opt-out" system confusing and some find it difficult to navigate
  • Users generally do not trust large data sharing schemes (e.g. care.data) unless they know what it will be used for
  • Users' comfort with sharing data differs based on the professional group and usage criteria
  • Existing solutions do not allow patients to see who has viewed their information, despite this being important to them

At this point I'd do a whole load of user interviews, but given the time constraints we'll skip that and go off the data we already have. The bits I'm least sure about which I would have asked about in interviews are:

  • How do you view the NHS? (i.e. is there understanding it's made up of different organisations)
  • Who do you expect to be able to see your health data? (e.g. notes, test results, appointments, etc)
  • Who would you be happy / not happy sharing your data with, if all ways of knowing it belongs to you had been removed?
  • What level of control would you want about who could see / use your data?
  • What level of knowledge would you want about who had seen / used your data?

Of course, this would fail any service standard assessment worth its salt as there's been no direct user engagement!

00:57 to 01:15

On behalf of my imaginary users I've created a series of user needs using the early research. In the real world I'd record how many times I heard each, and from which user groups to ensure I'd been comprehensive enough and to help with prioritisation exercises.

ID As a(n) I need So that
01 English citizen To set which categories of professional (e.g. doctor, pharmacists, researcher, pharma company) can access my identifiable data I can control which categories of practitioner can access my data
02 English citizen To set which purposes my identifiable data can be used for I can control what purposes my data can be used for
03 English citizen To see who has accessed my identifiable data I can check for suspicious activity and verify my wishes are being respected
04 English citizen To see for what purposes my identifiable data was accessed I can check for suspicious activity and verify my wishes are being respected
05 English citizen To report any access to identifiable data I do not agree with It can be checked in line with "need to know" basis rules
06 English citizen To set which purposes my anonymous data can be used for I can choose which types of research and/or planning my data can be used for
07 English citizen To understand which organisations have used my anonymous data and for what purposes I can opt-out or object to specific uses I disagree with
08 Prospective research participant To be able to provide consent for specific studies I can override any previous preferences for specific studies
09 Prospective research participant To note my willingness to be contacted about studies my data says I might be interested in I can be contacted and consent to research I agree to
10 Commercial app user To be able to control access of specific apps I've chosen to my healthcare data I can access services I have chosen to pay for
11 Second language English speaker Information to be available in my chosen language I can fully understand how my data is being used

01:15 to 01:21

Time is ticking pretty quickly (I've overshot the time I allocated for the Disco by a fair bit) and it looks like I definitely won't be able to address all of the needs given above so it's time to carry out a quick prioritisation exercise. My favourite framework for this is the MoSCoW (Must, Should, Could, Won't) way of grouping needs.

I'd usually do this with a workshop style exercise with relevant people in the room, but again, given time I've used a workshop with sample size (n=1 - my girlfriend) to categorise the needs. I paused the clock and gave her 5 minutes to prioritise.

Hmm... The importance of user research - I probably wouldn't have rated these in the same way. Worth saying that this is why having a diverse group of user research participants is important since this may affect your prioritisation - though obviously you may need to rearrange a little for technical or business reasons.

01:21 to 01:35

There's 40 minutes to go and we've got three needs which are rated as 1* (the highest priority).

  • I want to see for what purposes my identifiable data was accessed
  • I want to understand which organisations have used my anonymous data and for what purposes
  • I want information to be available in my chosen language so I can fully understand how my data is being used

Three is probably the limits of my speedy prototyping. I'd probably check where users expect to see these settings, but knowing from the Discovery that the existing service is already in the NHS App that's probably where it belongs. The easiest way to do this is using the NHS Prototyping Kit so it's time to download into my working folder.

Pause the clock - I don't have Node installed :-( - one quick Node install later and I'm ready to go.

01:35 to 02:00

First order of business - choose a name for the service. I've gone for View how data from your health records has been used.

One of the trickiest things creating the first (start) page of this prototype is that there's a lot of jargon in health privacy. I'd want to do user research to confirm it - but my hunch is that anonymised / identifiable are not widely understood. I've made a start, but I'd definitely want to iterate this to make sure it matches the NHS Content Style Guide.

Well I've spent far too much time on that and only have 7 minutes left for the rest of the design (eek!).

02:00 to 02:26

I didn't use that 7 minutes well and spent another 26 minutes to get something good enough. The trickiest thing about this design turned out to be the same issue as above - the content issue. It's really hard to make healthcare terminology easily understandable.

Were this a real project, I'd probably spend most of my effort checking the content and getting the level of detail and wording correct.

I've included screenshots below:

Appendix

Research Notes

I've included my raw research notes to give an idea of what information went into the above assumptions:

Proudly powered by Pelican, which takes great advantage of Python.