Expand support for feature comparisons

[ericbuckley]

Summary

NBS has requested that we add additional fields for feature comparisons. We won't need to block on any of these features, but we do need to have the ability to compare them in the second half of the algorithm.

Acceptance Criteria

• 3 new features, that can be parsed from a FHIR payload
• New tests for the PIIRecord.feature_iter method for the new features
• Documentation to recap the process below

Details / Tasks

1. Add the following values to recordlinker.models.pii.PIIRecord
   • SSN (should validate that its 10 digits and conform to XXX-XX-XXXX format)
   • Race (need an Enum with the 8 races identified here)
   • Gender (need an Enum with the 5 genders identified here)
2. Add the above 3 to recordlinker.models.pii.Feature, and additionally add 3 more
   • Telephone
   • Suffix
   • County
3. Rename recordlinker.models.pii.PIIRecord.field_iter to recordlinker.models.pii.PIIRecord.feature_iter
4. Update recordlinker.models.pii.PIIRecord.field_iter to extract the 6 features above
5. Update recordlinker.linking.fhir_record_to_pii_record to extract the 6 features from a FHIR payload
6. Add documentation to the docs/ directory to explain the process of adding a new Feature

Background / Context

This is the NBS Request we received for expansion

Include additional fields like race, gender, county for matching
Add the following fields as available options for blocking or matching configuration:

- Second last name
- Second middle name
- Suffix
- ID type
- ID value
- ID assigning authority
- Telephone
- Race
- County
- Gender
    - Need to determine which field in NBS to use for comparison.
    - The assumption is to use the Transgender Info field since it is a dropdown list.
    - Additional Gender field might also have gender information although it will be very difficult to use if possible since it is a text field.

Dependencies

#23

[ericbuckley]

@cbrinson-rise8 I'm going to remove your name from this one for the time being. If you have time to work on it this sprint thats awesome, but I want to prioritize #5 over this, as I think that will be more important for our Sprint 14 demo.

[alhayward]

@cbrinson-rise8 @ericbuckley To make sure I'm understanding:

1. NBS mentions "for blocking and matching", but we are deciding to only provide support for a select few of these additional fields for matching, correct?
2. I'd be curious why NBS is interested in supporting sensitive demographic fields like Race and Gender for Patient RL. Was there any more info NBS shared as to why they want these fields supported? (Did STLT customers request these fields?) CC: @monicamq
   • BTW, when supporting Race and Gender for matching, we need to evaluate them on exact match, not fuzzy match (like Sex, "M" or "F") because they are fixed categorical variables and do not communicate lexical similarity (e.g., "John" vs, "Jon").

[ericbuckley]

@cbrinson-rise8 @ericbuckley To make sure I'm understanding:

1. NBS mentions "for blocking and matching", but we are deciding to only provide support for a select few of these additional fields for matching, correct?

2. I'd be curious why NBS is interested in supporting sensitive demographic fields like Race and Gender for Patient RL. Was there any more info NBS shared as to why they want these fields supported? (Did STLT customers request these fields?) CC: @monicamq
   
   * BTW, when supporting Race and Gender for matching, we need to evaluate them on exact match, not fuzzy match (like Sex, "M" or "F") because they are fixed categorical variables and do not communicate lexical similarity (e.g., "John" vs, "Jon").

1. Correct, the only one I'm considering adding as a Blocking Key right now is SSN, as I'm guessing it could be used in use cases similar to the MRN blocking key. I have discussed this with Aparana multiple times on calls, she is ok with this decision.
2. I believe all of these requests have come from Julie, we can email her if you're interested in what use cases they are for.