API - Single user with multiple roles

[mstanton1]

Under #19997 the UI can display a individual with multiple roles. For instance, a user may have been a significant individual with a certain set of type of influence / influence range for one period of time, and then acting as a significant individual in another type of influence / influence range for another period of time for the same company. The same party may also be noted as a significant individual with other companies. Currently, designs support identifying a person (e.g. Abby Adams) in multiple roles. However, rules are not defined for how to confirm one person (e.g. Abby Adams) is the same as another person (Abby Adams).

Profile will enable us to identify a person as the same across reports as Significant Individuals. This ticket is to implement other logical ways to collapse a person (e.g. if Name + SIN Number match consider the person as the same?).

[mstanton1]

@thorwolpert can you review this ticket and provide your thoughts on the ways that we could quite confidently identify a SI as the same as another SI? Do you think Name + SIN is sufficient? If we matched on Name + SIN since we currently have one name field I'm imagining we'd need to compare on the full name (if there was first/middle/last it might be sufficient to say first name + last name + SIN).

[thorwolpert]

ICBC, Ministry of Health and BCSC have determined a way to reconcile name/account mismatches, but it's not great. You can probably tap Sarah to find out about what they do.

We do nothing to validate the SIN and match against the persons name, so we could get all sorts of errors with this as well. I doubt it's the same, but the Ops team used to have 4 FTEs hoping on businesses entering and using the wrong BN, so I'm going to assume there is some error rate.

You may find other tix already on this subject here and on the other boards under Entity Resolution

[mstanton1]

To tackle after further profile discussions.

Options

• could match on name + SIN (note, ideally we don't collect SIN)
• could match on name + date of birth
• could match on a profile identifier

In the first two cases there could be typos or slight differences in how info is entered causing us to not match where a match should be made. Or there could be more than one person with the same info causing a match that's invalid. If either of those matching parameters were used we'd need some sort of warning in the UI that a match may not be correct.

I think we should park this and re-add it under the Profile epic. For now, search does not have to include grouping of individual results. @J-Baese @forgeuxGH5 @thorwolpert any concerns with this approach for MVP? For design, I believe we'd just leave off the details page on search because it just took the info and compiled it. Would the flow end where a user opened a record from the search results table then? Do we have a design for that or need another ticket?

[forgeuxGH5]

We would have to look at changing the interaction for the person link from the business search. If there is no unified person page there might still be value in linking to a page for that one business (you'd still be able to get their address etc. quickly), but there could other ways to get to that info (e.g., tooltip). Users might also want to run a search on a person's name from the business search to get the full list of business for that person so we might want to look at supporting that. I don't know if we need a new design for the un-collapsed result - we just don't collapse on the Name and Information columns - that would be super fast to mock-up though

[mstanton1]

Moving into profile epic. The ability to group will be closely tied to our enhanced ability to identify a user as the same. If this is not solved with profile we can look at alternate approaches at that time.

[J-Baese]

We did suggest that there might be a way to recommend other matches within the detail view without actually combining them based on potentially a combo of identifiers like suggested above. ie: This person possibly matches these (3) other listings (could be an expander table with the (3) to view).

[forgeuxGH5]