|
| 1 | +--- |
| 2 | +title: Dealing with duplicate learners |
| 3 | +description: We can only have unique learner records in our service so we need to deal with users adding a duplicate learner to prevent this. |
| 4 | +author: |
| 5 | + name: Mark Portnell |
| 6 | + |
| 7 | +date: 2024-04-15 |
| 8 | +modified: 2024-05-20 |
| 9 | +tags: |
| 10 | + - claims-version-8 |
| 11 | + - manage-claims |
| 12 | +aside: |
| 13 | + title: Claims Prototypes |
| 14 | + content: | |
| 15 | + [View claims v8 prototype](https://adult-social-care-7fe9bafd955a.herokuapp.com/claims/prototypes/design/v8/) |
| 16 | + Password: bsaasc123 |
| 17 | +--- |
| 18 | + |
| 19 | + |
| 20 | + |
| 21 | +## Why we did this work |
| 22 | +Learners in our service are unique entities in that they have a unique identifier in their national insurance number. Whenever a learner is added to the service for use in a claim that learner is saved and can be used in future claims. As a result of this if a user were to add a new learner and the National insurance number matches a learner that is already in the system then we need some mechanism to deal with this to prevent duplicate learners being added to the service. |
| 23 | + |
| 24 | +## What our ideas were |
| 25 | +Through some exploration of the problem space we identified three primary scenarios that might lead to above situation: |
| 26 | +1. A user mistakenly tries to add a learner again as they didn't search correctly and therefore doesn't realise the learner had already been added. |
| 27 | +2. A user mistakenly tries to add a learner again because they searched correctly but the learners details have changed (eg name change) |
| 28 | +3. A user mistypes a NI number when adding a new learner and this inadvertently matches an existing learner. (Rare) |
| 29 | + |
| 30 | +For each of those scenarios we identified an appropriate corrective action: |
| 31 | +1. Add the existing learner to the claim instead of creating a new learner record. |
| 32 | +2. Update the existing learners record and add that to the claim. |
| 33 | +3. Go back to correct the mistake in the add new learner form. |
| 34 | + |
| 35 | +To allow the user to self identify their scenario we had the following hypothesis: |
| 36 | + |
| 37 | +>**We believe that** allowing users to compare information between the intended new learner and the matched learner record |
| 38 | +>**Will be a useful feature for** submitters |
| 39 | +>**As it will** help them identify the correct follow on action for their scenario. |
| 40 | +
|
| 41 | +We first explored existing patterns across the GOV.UK space and came across the (compare information pattern)[https://design.homeoffice.gov.uk/patterns/compare-information] in the home office design system. Given our concerns about being able to test this with users before development we felt using a existing pattern would minimise risk. We incorporated this pattern into our service and allowed for the relative corrective actions. Unfortunately due to tight deadlines we did not have the time to explore learner record updates and this was something that was added to the backlog. |
| 42 | + |
| 43 | + |
| 44 | + |
| 45 | +## How we tested our ideas and what we found |
| 46 | +Unfortunately due to aggressive deadlines we were unable to test this pattern properly before development or private beta. |
| 47 | + |
| 48 | + |
| 49 | +## What we will do next |
| 50 | +While we feel the use of this pattern untested in our service is low risk due to it being taken from the home office design system we still have concerns around the lack of corrective action that deals with updating learner records. We have agreed that this is something we will try and monitor during private beta and conduct further research as necessary when we look to address the issue of updating learner records. |
0 commit comments