🆔Feature Passport Sensitive data

Status Feature Passport

STATUS	OWNER	DATE
In proposal	Yassin	03/02/22 Edited by Saska: 7/2/22
In refinement - Design Research	Saska	7/2/22 Edited: 8/2/22 edited: 10/02/22
In refinement - Technical Research/Feedback
In development
In QA/ Testing
In Final state

Analysis

Current state

In the Module Personen, we can find the a personal information page. On this page a user can view and edit personal information.

This contains the following information:

Voornaam, achternaam, roepnaam

With the DPO it was agreed in the DPIA that a user needs to select a reason before they can consult or edit sensitive personal data. This reason will be recorded and can be retrieved for auditing/control purposes later. This was suggested by the DPO as a way to ensure easy access to the information, while ensuring responsible use of this sensitive information.

The sensitive information includes:

• Date of birth (Date - if possible without data picker and with placeholder/preview text 01-01-1900 )

• Gender (codelist - single select)

  • Vrouwelijk

  • Niet gekend

  • Mannelijk

  • niet van toepassing

  • Voorlopige gegevens

• National registry number (11 numbers - unique value)

  • This is a Belgian National Registry Number (Rijkregisternummer of BIS-nummer). In discussion with the ISD it was pointed out by Bart M. that non-Belgian identification numbers are of little use to share it with other governmental agencies. So users are expected to not register non-Belgian identification number (eg. US social security number).

• Nationality (codelist - multiple select)

The code list (to consult sensitive data) contains the following reasons:

• In kader van administratief toezicht

• In kader van een screeningsdossier

• In kader van een erkenningsdossier

• In kader van een wijzigingsdossier

• In kader van een informatie-uitwisseling (cfr. protocol) met een overheidsinstelling

• Aanmaken van een persoon (only in the background)

The end-users that would use this information are related to ISD and LOW. The total number of users of this functionality is estimated to be around 20 end-users.

Value	Mandatory	Error	Helptext
Voornaam	✅
Achternaam	✅
Roepnaam	❌
Geboortedatum	❌	Dit is geen geldig geboortedatum. Gebruik het formaat DD-MM-JJJJ	DD-MM-JJJJ
Geslacht	❌
Nationaliteit	❌
Rijksregisternummer	❌	Only if filled out incorrectlyVul het (elfcijferige) Rijksregisternummer in. Only if Rijksregisternummer already exists Dit rijksregisternummer al tot een persoon. Als je denkt dat er een fout is, [meld het ons.]	Structure of a rijksregisernummer is preformatted see ticket https://binnenland.atlassian.net/browse/OP-522

🤩 Expectations

In this feature passport, we will tackle these expectations:

1. Reading Sensitive data

The user with the correct rights must be able to request the view of sensitive data.

Sensitive data include:

• Date of birth

• Gender

• Belgian National registry number

• Nationality

When the data isn't available the user cannot request to see it to avoid confusion of requesting to see an empty piece of data.

The use must give a reason to request the data, and this reason will be recorded and stored.

The reasons are:

• In kader van administratief toezicht

• In kader van een screeningsdossier

• In kader van een erkenningsdossier

• In kader van een wijzigingsdossier

• In kader van een informatie-uitwisseling (cfr. protocol) met een overheidsinstelling

• Aanmaken van een persoon

The data will be available for the user to see until the user refreshes the page. This is how it currently works.

2. Editing Sensitive data

A user with the correct rights must be able to edit sensitive data as well as add/create sensitive data for a person that doesn't have them yet.

⚠️ To add/edit sensitive data, a user must first request to see the data! Otherwise the user will be able to tap on edit to see sensitive data without a reason being recorded.

3. Deleting Sensitive data

At this moment we don't foresee any limitations that stop a user from emptying the gender, national registry number or birth date.

Informational purposes: we have plans to limit the ability to edit the first and last name based on the type bestuurseenheid. (For example Erediensten case managers can only edit persons related to an Erediensten organization).

In case a field is being emptied, it must be stored as NULL, so that there is no unnecessary relations related to the person.

4. Creating Sensitive data

The user is advised to search a person before they can add a person. If they choose to add a person, we foresee the following validations:

• The national registry number needs to be unique. Out of scope: We refer in the error who the national registry number is related to.

• The gender, birth date, nationality and national registry number are not mandatory

• Gender codelist (new):

  • Vrouwelijk

  • Mannelijk

  • Andere

  • Niet gekend

5. Searching Sensitive data

Given that the data is in a separate graph, I don't know whether this data (for example birth date) is searchable, and whether it is very time-consuming to achieve this? nordineClaire Lovisa

The current search allows to search on the first and last name.

Out of scope:

• The user may want to search on the national registry number if they have it. But this is not an advisable search pattern, currently this data is not present.

• There is also the case where multiple persons have the same name. One organisation and corresponding position which they are related to can be shown in the result screen. An alternative is that the birth date is shown, as this helps to differentiate between people with the same name.

🤔 Discussion points

Q: How long is the information available? (In case of reading and editing sensitive data)

A: Selected option = When they refresh the page. This is how it currently works.

The DPO did not stipulate this exactly, and we are free to choose an implementation, as long as it reasonable and defendable.

Discussed:

We are interested to know what is easily feasible from a technical standpoint. The user receives sensitive information, but what would cause this information to be hidden. There is no requirement to only show this information for a very short timespan, but it is advisable that this information is hidden once the user has consumed this information.

There is discussion on when to request the user to request this information.

• Is it when they left this page? (There is the exceptional scenario, that once a user edited and saved the sensitive data (so going from one page (edit page sensitive date) to the other (read page personal information) that they from a UX perspective would like to see that the changes went through successfully).

  • Is it when they go to another main tab or a sub tab?

• Is it when they refresh the page?

• Is it when the session cookies expire?

• Is it when a pre-defined set of time (for example 1 hour) has passed?

Solution

Design

Links

• Legacy figma file

• Figma OP directory

1. Viewing sensitive data

To view sensitive data, a user with the correct rights needs to request it. To do this, the user clicks on "Consulteer" (Request) next to the label. It does not matter which "Consulteer" button the user clicks, as requesting 1 type of sensitive data will show all the available ones.

Only the data that is filled in can be requested (e.g. If there is only a DOB available, then the following screen will only show a label for DOB to request.)

Once the user clicks on "Consulteer", they will be presented with a screen asking them to fill in a reason for requesting the data. This reason will be recorded and saved. To be transparent, we will also tell the user that this reason will be recorded.

Once the user selects a reason and clicks on "Volgende" the available data will be visible for the user, until the user refreshes the page.

2. Editing/adding/deleting sensitive data

Value	Meaning	Process
Creating sensitive data	Adding sensitive data to a person for the first time	This process does not need a data request flow as there is no previously filled in data. This can be part of the person creation flow, but can also be possible if a person already exists but doesn't have any previously added sensitive data. In this case, when a user clicks on edit, all the sensitive data fields show up without the user having to give a reason.
Editing sensitive data	Changing existing sensitive data with updated information	The user needs to first request to see the data to be allowed to do this.
Adding sensitive data	Filling in sensitive data fields which were previously empty, for an already existing person	The user needs to first request to see the data to be allowed to do this.
Deleting sensitive data	Taking a filled in field and deleting the data in that field	The user needs to first request to see the data to be allowed to do this.

2A. The user edits/adds/deletes data after having requested to view the data

2B. The user wants to edit/delete/add data but hasn't requested to see sensitive data yet

The user can edit personal information that isn't sensitive (name, last name, nickname). If they want to edit sensitive data they have to request it first and follow the request flow.

The user clicks on "Consulteer en bewerk"

The user gives a reason and after clicking "Volgende", goes straight the the edit screen where they can edit/add/delete data.

Technical

TLDR:

• Current solution looks good and doesn't require a lot of modification in the backend.

Technical Research Conclusions

1. Technical research conclusion on "Dit rijksregisternummer behoort tot [person-link]."

• Should be changed to something like "this RN is already used by another person"

• if we agree to "bypass" the reason system, an improvement in the future is proposed in point 5

2. Technical research conclusions on "When the data isn't available the user cannot request to see it to avoid confusion of requesting to see an empty piece of data."

• this is already implemented in the backend, so it should be good (unless some small bug to fix that we will discover during frontend implementation)

3. Technical research conclusions on "The use must give a reason to request the data, and this reason will be recorded and stored."

• Currently we don't store which field was requested and we return all the fields to the frontend. It should be ok as in the solution proposed we show all the fields no matter which button was clicked, but if at some point you would like to know who requested something, it will look like this: "Jean requested sensitive information for Pierre with the reason X" If you want to have something different, such as "Jean requested birth date of Pierre with the reason X", it will require backend changes.

4. Technical research conclusions on "In case a field is being emptied, it must be stored as NULL, so that there is no unnecessary relations related to the person."

• This will require some changes in the backend to avoid unnecessary empty resource

5. Technical research conclusions on "Creating sensitive data"

• Ok to refer who the national registry number is relate to, but we will not record that X asked info about Y , where Y has the RN that was attempted to add as duplicate. If we still want to record this, it will require some changes in the backend (feasible), could be something we add in the future, like a new reason "Requested to add while already exist"

6. Technical research on "Searching Sensitive data"

• It is feasible to search over them, we just need to decide what strategy to adopt in that case. For example, if you search all person with gender Male, we can do the search on the backend side, then before returning the results found, save a reason for each person returned (e.g of reason code could be like "request for search")

• This needs business analysis