Relocate 'other contact information' from Module 1 to User Profile

[brotzmanmj]

In the February release, add the 'Other Contact Information' move questions that were formerly in Module 1 (removed in the January 2025 content changes to Module 1) to the User Profile.

Here are the CIDs we are referring to:

These pertain to Alternate Address (When you joined this study, you gave us your mailing address. Are there any other mailing addresses that you use?)
646504105 | When you joined this study, you gave us your mailing address. Are there any other mailing addresses that you use?
284580415 | Alternative address line 1
728926441 | Alternative address line 2
907038282 | Alternative address city
970839481 | Alternative address state
379899229 | Alternative address zip

These pertain to Alternate Contact (Sometimes we find that people have moved when we try to contact them again. It would be helpful if you could give us the contact details of someone close to you (such as a relative or friend) who would be willing for us to contact them if we are unable to reach you. Please leave this section blank if you do not wish to provide these extra contact details.)
661719912 | Alternate contact first name
801653230 | Alternate contact last name
286149234 | Alternate contact mobile phone
318130543 | Alternate contact home phone
750097000 | Alternate contact email

Tasks:

Content Finalization:

• Move content in English and Spanish as it appeared in Module 1 to the User Profile content document. Will need to rephrase the lead-in question on Alternate Address. (Aileen and Amelia)
• Get the Spanish changes certified by Glyph (Kaitlyn)
• Submit UP with this change to the IRB (Kaitlyn) - submitted 2/3, IRB approved 2/4

Analytics:

• Update Variables in Data Dictionary. DECISION: Update Primary Source=Recruitment, Secondary Source=User Profile. CIDs to the right would keep as is. Variable names should have prefixes updated to new primary and secondary sources. @mnataraj92 @hullingsag
• Add Alternative Address fields to User Profile History nesting structure. DECISION: Edits to Alternative Address fields will be saved under the User Profile History nesting structure. Note, variables for Alternate Contact should not be added to the UP History. Can be edited or deleted by the participant. @jacobmpeters

DevOps:

• Move existing variables with data from Module 1 Survey collection to Participants collection. DECISION: Data will be moved from module 1 table to participants table. @JoeArmani
• Update the PWA User Profile page to add these questions and fields. See Box links in comment below for specific intro text and placement of fields. (Priority 1) @bransteitterbr @JoeArmani
• Update the SMDB Participant Details page to allow for edit capabilities under same rules as other information on that page (pre vs post verification). See decision above regarding storing of data under UP Ux variable. (Priority 2) @JoeArmani
• Update the PWA MyProfiles page to add both 'Alternative Address' and 'Alternate Contacts' with edit capabilities. See decision above re storing alternative address changes under UP Hx nesting structure but not retaining history of alternate contacts. Use same rules as other info on that page (e.g. edits not allowed for participants with verification status other than 'verified'). Tied to #1207 to clear Physical Address and Alternative Address fields in MyProfiles page when participants are editing data. (Priority 3) @JoeArmani
• Upon launch in prod, populate the existing data from Module 1 into the UP variables so it can be edited in the future. @JoeArmani

Other decisions:

• USPS API. DECISION: Wait to implement USPS API on alternative address fields until later release.
• - Variables should not be retained in the event of data destruction. Do not add to stub record.

Order of Operations:

• Analytics to update data structure for Alt Contacts and Alt Addresses @jacobmpeters
• Analytics team to flatten data
• DevOps to build out UI changes to PWA @bransteitterbr @JoeArmani
• Move the data from Mod1 to UP in dev tier @JoeArmani
• Test. Test both old participants who had already answered the questions in Mod 1 plus new participants who have not submitted UP/ answered the question in mod 1.

[rohanjay10]

Hi all, I've included my notes from the 1/23 initial call here: https://nih.app.box.com/file/1761770747996
Please review the doc if any info needs to be changed/addressed

[robertsamm]

Tracked versions of the User Profile updates including updated language of lead-in changes and placement of alternate contact and alternate address fields are located on Box here:

• English: https://nih.app.box.com/file/1757592323926
• Spanish: https://nih.app.box.com/file/1756153425365

[robertsamm]

@rohanjay10 @mnataraj92 I have updated the original github issue above with the updated decisions and tasks needed that came out of our kickoff meeting. Can you please review and make sure everything is correctly captured and we have the full list of tasks and requirements noted?

[rohanjay10]

@robertsamm Thanks for the updates. Yep I can review it, would you like me to incorporate those updates into the User Profile Requirements doc(with track changes) as well? I'm working through that doc to check that it has updates necessary for previous UP items.
UP requirements: https://nih.app.box.com/file/1674557082093

[robertsamm]

Hi @rohanjay10 Let's leave the UP Enhancements Requirements doc to the items that it originally contained (e.g. still use it for the USPS API updates) but otherwise we'll let that retire as it's getting pretty busy. The requirements for this task can all just remain documented in this github issue.

[rohanjay10]

Hi @robertsamm that sounds good. @anthonypetersen @bransteitterbr @Davinkjohnson @sonyekere keeping you all in the loop for the DevOps components above

[brotzmanmj]

I like the list structure above. Rohan can you add who is responsible for each item? and can people comment when their tasks are done so those next in line can begin work? thanks

[rohanjay10]

Hi Michelle, yes I can work on adding those responsible for the tasks(I may need to check for certain items)

[rohanjay10]

Hi all, as discussed with @jacobmpeters over Teams, Jake's not sure if the data would need to be flattened as the UP table does not have a data structure compatible with the Analytics flattening approach. Currently the UP table is not flattened in the Analytics table on BQ and not used for downstream analyses

[jacobmpeters]

Hi all, as discussed with @jacobmpeters over Teams, Jake's not sure if the data would need to be flattened as the UP table does not have a data structure compatible with the Analytics flattening approach. Currently the UP table is not flattened in the Analytics table on BQ and not used for downstream analyses

Correct, the user profile history is not currently included in our flattening pipeline because the data structure is not compatible with our flattening approach and it has never been used in any downstream analytics. If we need to do any analytics on these data, I will need to develp a custom flattening approach for the user profile history. I expect this to take some time, so I'll defer this issue until it is needed.

When variables are removed from module1 I will just need to delete them from the from the flattening configuration file for module 1.

@KELSEYDOWLING7 Do you currently do any analytics with these variables?

[KELSEYDOWLING7]

They're currently in the monthly module 1 summary statistics report but I can easily remove them

[robertsamm]

Noting that the tasks related to content finalization are done. The UP content changes were submitted to IRB today, 2/3 (pending IRB approval).

For the PWA User Profile Page:

• The tracked versions of the content for DevOps to use to make the updates in the PWA User Profile Page are linked above in this comment: Relocate 'other contact information' from Module 1 to User Profile #1186 (comment)

For the SMDB Pt Details page:

• Add 'Alternate Address' and 'Alternate Contact Fields' after 'Physical Zip' but before 'Birth Month'.
• See original issue above regarding storing and retaining edits vs. not in the UP Hx var.

For the PWA MyProfiles page:

• Please add 'Alternate Address' and 'Alternate Contact' fields after 'Physical Address' but before 'Sign In Information'. With those categories as the header titles.
• @depietrodeanna should we add any explanational text on the MyProfiles page to remind pts why we are collecting this info? Maybe 'if you have additional mailing addresses that you use' for Alt Address and 'To use to recontact you if we are unable to reach you.' for Alt Contact? Please confirm lang or if you don't think it is needed. Will also need Spanish translation.
• See original issue above regarding storing and retaining edits vs. not in the UP Hx var.

[depietrodeanna]

@robertsamm yes I agree that a reminder/explanation makes sense for these two additional files on participant's My Profile page.

Under the "Alternate Address" header please add the following explanatory text:
"For any other mailing addresses you have"

For the "Alternate Contact" header, add the following explanatory text:
"To help us get in touch with you if we lose contact"

I will get this Spanish translated and add here.

[rohanjay10]

Hi @depietrodeanna for the Alternate Contact text would it be "To help us get in touch with if we lose contact", instead of "loose contact"

[depietrodeanna]

@rohanjay10 HA yes, apologies for the typo.

[depietrodeanna]

@rohanjay10

Updating with Spanish content here:

English -
Header: Alternate Address
Explanatory text: For any other mailing addresses you have

Spanish-
Header: Dirección alternativa
Explanatory text: Para cualquier otra dirección de correo postal que tenga

English-
Header: Alternate Contact
Explanatory text: To help us get in touch with you if we lose contact

Spanish-
Header: Contacto alternativo
Explanatory text: Para ayudarnos ponernos en comunicación con usted si perdemos contacto

[rohanjay10]

@rohanjay10

Updating with Spanish content here:

English - Header: Alternate Address Explanatory text: For any other mailing addresses you have

Spanish- Header: Dirección alternativa Explanatory text: Para cualquier otra dirección de correo postal que tenga

English- Header: Alternate Contact Explanatory text: To help us get in touch with you if we lose contact

Spanish- Header: Contacto alternativo Explanatory text: Para ayudarnos ponernos en comunicación con usted si perdemos contacto

@depietrodeanna Thanks for sharing. Hi @JoeArmani keeping you in the loop on the English/Spanish explanatory above text in the MyProfiles page

[robertsamm]

User Profile content changes were IRB approved today, 2/4

[robertsamm]

Hi all, please be sure to provide updates on this github issue. Are the variables finalized or still being updated? @hullingsag @cunnaneaq @mnataraj92

[cunnaneaq]

They're deprecated from the M1 section of the data dictionary

[mnataraj92]

Autumn and I moved the variables from Module 1 to the User Profile section of the data dictionary. The concept IDs for the actual variables are the same with the primary and secondary sources updated.

Alternative Address fields will be saved under the User Profile History:
646504105 When you joined this study, you gave us your mailing address. Are there any other mailing addresses that you use?
284580415 Alternative address line 1
728926441 Alternative address line 2
907038282 Alternative address city
970839481 Alternative address state
379899229 Alternative address zip
When saved under user profile history they will be nested under 569151507.

Alternative contact fields will not be saved under User Profile History:
661719912 Alternate contact first name
801653230 Alternate contact last name
286149234 Alternate contact mobile phone
318130543 Alternate contact home phone
750097000 Alternate contact email

[JoeArmani]

Hi, it looks like I'll be taking on all these bulletpoints. I've read through everything and have two questions:

(1) Are the migrated variables going in the top level (non-nested) in the participant profile? These were nested under three separate questions in Mod 1. Non-nested seems fine...I just want to make sure we're on the same page.

(2) What refusal/data destruction statuses (if any) are we accounting for when migrating data from Mod 1 -> participant profile?

[brotzmanmj]

hi,

1. I defer to @mnataraj92 for this decision

2. I would assume that if automated data destruction is working as expected, any data that qualified for destruction would have already been destroyed within mod 1 ands therefore not available to be migrated. Anything not yet qualified for data destruction and therefore still exists in mod 1 should be migrated. These variables will not be part of the stub record and therefore should be destroyed upon future data requests. (@mnataraj92 please note that we should test this).l

[JoeArmani]

Great. Thanks @brotzmanmj

[mnataraj92]

Hi Joe, the alternate address variables and alternate contact variables should be top level variables. For the alternate address variables, these should be treated the way that we're treating the mailing address variables and physical address variables. So if alternate address variables are filled out, those should be top level. But if there's any edits to those variables, those edits should be nested under user profile history (569151507), but the current alternate address variables should be in the unnested versions of the variables (similar to mailing address and physical address).

'Alternate Contact' variables will never be nested/stored under the UP Hx. We will just overwrite that data. So these should always be top level variables.

I'm working on a test plan and will add that data destruction scenario to make sure that any data already destroyed remains destroyed upon migration (it should not be available to migrate to the user profile), and will test a pt that has the alternate contact & alternate address variables filled out to ensure that it's destroyed upon data destruction being run.

[JoeArmani]

Perfect. Thanks @mnataraj92

[jacobmpeters]

I think that my role in this workflow is just to update the flattening in BigQuery. I think this should be the last step in the order of operations since it relies on updates to the data structure in Firestore.