Universal set of blocking keys

[ericbuckley]

Summary

As we move towards a concept of only have N number of blocking keys available to customers, we need to determine exactly what those keys should be.

Acceptance Criteria

• [ ] A recommendation of ~10 blocking keys customers can pick from

Details / Tasks

We have 7 keys currently in use by the DIBBS_* algorithms, so at the very least we'll need these 7 going forward. There are likely a few more, which may provide good value for customers to optionally "block" with when retrieving from the database.

• birthdate
• sex
• zipcode
• last 4 of mrn
• first 4 of first name
• first 4 of last name
• first 4 of address

Background / Context

Having a universal set of blocking keys, rather than unlimited, has many advantages. a) its easier to drive a UI for users to configure their algorithm b) we can optimize the database up front for the appropriate blocking key indexes c) we can limit customers to keys we know are useful and not allow them to make too many inappropriate decisions.

[ericbuckley]

@alhayward now that we're in the process of adding more identifiers to the list of feature comparisons, I'm wondering if it makes sense to also block on those? For example, I could see similar reason for wanting to block on the last 4 of SSN if blocking on the last 4 of MRN provides value. In a PHA where SSN is more readily available than MRN, this might be a better blocking key. Thoughts?