Eligibility, Humanity, and Minimisation

by | May 14, 2020 | ICT4D, Identity |

“Can you tell me how many people are registered in this project?”

“Registered or enrolled?”

“What?”

“Do you want to know how many people are registered or enrolled in this project?”

“I don’t understand. I want to know how many people we’ve registered in this project and are engaging with us.”

“So enrolled then…”

“No, registered…oh I don’t know, I just want to know how many people we are working with, why is this so difficult, I thought one of the benefits of doing this digitally was having this information at our fingertips!”

And so it went. I’m ashamed and a bit embarrassed to admit I was person 1 is this discussion. My long suffering colleague, Benny, was person 2. We had this conversation in different ways multiple times before I got it.

Registration and enrolment are different things. It seems quite basic now, especially if I think about a different context like online platforms. For example, you register on the platform as a whole, then enrol in courses you’d like to take.

Eligibility is different again. Eligibility is about meeting a certain set of criteria. For example, are you over a certain age, have you completed a pre-requisite, and so on.

Identity is also different. It is much bigger, the sum of the parts. We often confuse identity with an identifier, especially in the digital space.

So why is this important?

One of the principles of responsible data and technology use is data minimisation. Or in regular english – collect only the data you need and when you don’t need it anymore, delete it. Another way to say it is, don’t speculate with data collection.

So ideally, we are not registering people who we won’t enrol in our projects. However, if we are, know the project eligibility criteria before beginning the registration process. And then, collect only the data you need to determine eligibility. If age is not a eligibility criteria, don’t collect date of birth.

Apply the same idea to access. If the task you perform requires you to greet the person by name, then you should have access to their name. However, if someone’s name, gender, age, test score, vulnerability status, etc. has no bearing on your task or role, then you should not see the name, gender, age, and so on.

And perhaps soon, we’ll start adopting processes to enable data portability so that the people we seek to serve can take the data about them, with them. And then, when they interact with us, we can ask ‘their data’ eligibility questions and simply receive ‘yes/no’ answers. Because often, that’s all we need.

And thank you Benny, your patience and kindness with me was greatly appreciated.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *