Align provider phone mapping with legacy behavior and exclude inactive cell phones

[mehansen]

Description

This PR addresses two JIRAs related to person phone numbers in RDB.

APP-461 — Phone mapping mismatches in COVID Lab Datamart, D_Provider, and D_Patient
RTR was not matching MasterETL's logic for filtering person phone numbers by use_cd and cd in several different scenarios, causing diffs in the aforementioned tables under certain circumstances. The root issue was that RTR conflated distinct phone types rather than treating them separately as MasterETL does.
The diffs were:

• D_Provider work phone is explicitly "office" type (cd = O, use_cd = WP) in MasterETL, but RTR filtering logic was allowing cell phones.
• COVID_LAB_DATAMART provider work phone is explicitly "workplace phone" type (cd = PH, use_cd = WP) in MasterETL, but RTR was referencing nrt_provider/D_Provider work phone, so getting the office phone or cell phone.
• D_Patient work phone is explicitly "workplace phone" type (cd = PH, use_cd = WP) in MasterETL, but RTR was allowing other cd values.
• D_Patient home phone is explicitly "home phone" type (cd = PH, use_cd = H) in MasterETL, but RTR was allowing other cd values.

To fix:

• Two new columns (phone_work_phone, phone_ext_work_phone) are added to nrt_provider to store the PH-type work number separately from the existing phone_work/phone_ext_work columns (which hold the O-type office number).
• sp_covid_lab_datamart_postprocessing is updated to read from the new columns for ordering provider phone.
• The telephone query in sp_provider_event is simplified from a UNION ALL and updated to allow other cd values besides O and CP.
• Phone processing logic in DataPostProcessor and Phone.updatePerson() is refactored to map each phone type to the correct field based on both useCd and cd. Note that provider work phone and patient work phone are mapped differently which matches MasterETL.

APP-595 — Inactive provider cell phone numbers incorrectly included
Discovered during APP-461 testing: RTR was populating D_PROVIDER.PROVIDER_PHONE_CELL with cell phone records that had been soft-deleted in ODSE (i.e., RECORD_STATUS_CD != 'ACTIVE'). This was carried over from MasterETL, but SME review confirmed it is a bug. This PR fixes it by adding an ACTIVE record status filter to cell phone lookups for providers, consistent with how inactive records are already excluded for provider work phones and patient cell phones.

Related Issue

APP-461 | APP-595

Additional Notes

Per APP-595, the fix to exclude inactive cell phones is a deliberate divergence from MasterETL behavior; will update https://cdc-nbs.atlassian.net/wiki/x/A4BYfw to document the change.

Checklist

• I have ensured that the pull request is of a manageable size, allowing it to be reviewed within a single session.
• I have reviewed my changes to ensure they are clear, concise, and well-documented.
• I have updated the documentation, if applicable.
• I have added or updated test cases to cover my changes, if applicable.

[mehansen]

would love thoughts on better names for these, or other ways to differentiate between the two types of work phones

[ericnagel]

Are these two different types of work phones, or are they work phone (ex: 716-555-1212) and work phone extension (ex: 12345)?

[mehansen]

if you look at the fields above these you'll see

• phone_work and phone_ext_work which represent the phone (and extension) entered with Use = Primary Workplace and Type = Office in the UI
• these are different from phone_work_phone and phone_ext_work_phone which represent the phone (and extension) entered with Use = Primary Workplace and Type = Phone

we need both types in the nrt_provider table to replicate MasterETL behavior, but I'm cringing at the name for the ones I added

[ericnagel]

Oh then maybe:

• phone_primary_office
• phone_primary_office_ext

Also, maybe another issue but it appears that the area code is being saved in the country_code field.

[mpeels]

Excellent