New CIDs for Re-invitation Campaign Type and Re-invitation Date (March Release)

[robertsamm]

KPCO and KPNW are going to run through their 1st round of invitations in their catchment populations soon. They are preparing for a second round of contact attempts to re-invite patients they invited before that did not initially respond to the invitation. We would like KPCO/KPNW (and eventually all sites in the future) to share data about re-invitations with our system so we can track progress and response rates. Aiming to have the following items below finalized for an March Release.

To track re-invitations in our system, we will need the following 2 new CIDs:

• Re-Invitation Campaign Type: will have the same format and response codes as the current ‘Campaign Type’ variable. KP will push this to us when they initiate a batch of re-invitations.
• Re-Invitation Date: will be autogenerated by our system upon receiving the Re-invitation Campaign Type.

Tasks:

• Add the new variables and their descriptions to the Data Dictionary (@hullingsag)
• DevOps add the new variables to the API (@JoeArmani)
• Test sending of the new variables w/ KPCO + KPNW (@mnataraj92)
• Add to QC and Metrics Report - (@robertsamm to add in a separate github issue in the Analytics Repo)

Additional details:

• Sites will use the same token/PIN and Study ID for each re-invitation to to a recruit. They will not push a new record for the same person in the system.
• Sites will not need to push us the de-identified data again

[robertsamm]

Related Issues for QC and Metrics Requests:
QC: Analyticsphere/metricsReportsRequests#207
Metrics: Analyticsphere/metricsReportsRequests#208

[mnataraj92]

Re-invitation campaign type: state_d_280021666
Re-invitation date: d_439351436

Discussed with Nicole; re-invitation campaign type should be a state variable. The date/timestamp does not need to be a state variable (similar to the recruit type timestamp)

[brotzmanmj]

Discussed on leads call yesterday that sites will need to send Re-invitation campaign type: state_d_280021666 via updateParticipantData API in real time when they initiate each batch of re-invitations so that our system can set the date of re-invitation date d_439351436 accurately.

[brotzmanmj]

Slight wrinkle in this plan... Chicago started re-invitations last week. Amelia is sending them a message giving them guidance on how we plan to implement this and asking them to track re-invitation campaign type and date on their side for now.

However, since we are planning to autogenerate re-invitation date d_439351436, theirs will be incorrect if they batch push us the re-inv campaign type after the March release.

Suggestions? Would we ask them to push their date to overwrite our autogenerated date?

[sonyekere]

Amelia is currently working on the requirements for the QC and metrics. However, DevOps is okay to start, requirements have been finalized on that end.

[mnataraj92]

Documenting here that I spoke with Nicole and Re-Invitation Campaign Type will not be a state variable as it will be sent via updateParticipantData API.

Re-Invitation Campaign Type CID: d_280021666- sent by the site
Re-Invitation Date: d_439351436- autogenerated by our system upon receiving the Re-invitation Campaign Type

[robertsamm]

@hullingsag please work w/ Nicole to identify someone from Analytics to coordinate with KPCO and HFH to test this in dev and stage as Madhuri will be OOO

[JoeArmani]

Hi @robertsamm,

I have a few questions about this addition to the updateParticipantData API:

Questions:
(1) Will sites only send the token and re-invitation campaign type, or will they also send studyId or PIN for additional validation?

(2) It seems like we can validate:
Recruitment type (512820379) = Not active (180583933) since that’s set at the initial record creation and updated when an invited participant signs up. Are there any cases where this isn't accurate?

(3) We are setting the following two variables for the success case:
•Reinvitation campaign type (280021666): invitation type (from the same campaign type list as the initial invitation).
•Reinvitation timestamp (439351436). I have no questions about this one.
•Is that it, or am I missing anything?

Process (Please comment/correct/add to these if necessary):

1. Site sends reinvitation update with token, reinvitation campaign type, and ? (possibly other data for verification).
2. We search for the existing record, verify it is eligible for reinvitation (it has not been assigned), and add the reinvitation type and reinvitation timestamp CIDs (280021666 & 439351436).
3. We return success/failure based on the result of the operation.

[JoeArmani]

Slight wrinkle in this plan... Chicago started re-invitations last week. Amelia is sending them a message giving them guidance on how we plan to implement this and asking them to track re-invitation campaign type and date on their side for now.

However, since we are planning to autogenerate re-invitation date d_439351436, theirs will be incorrect if they batch push us the re-inv campaign type after the March release.

Suggestions? Would we ask them to push their date to overwrite our autogenerated date?

Hi @brotzmanmj,

Perhaps the most straightforward approach would be a one-time function to process the updates for anything prior to this release. If they could provide a spreadsheet with token, 280021666, and 439351436 for each invitation record, that update would be straightforward to write and process.

[robertsamm]

Hi @robertsamm,

I have a few questions about this addition to the updateParticipantData API:

Questions: (1) Will sites only send the token and re-invitation campaign type, or will they also send studyId or PIN for additional validation?

(2) It seems like we can validate: Recruitment type (512820379) = Not active (180583933) since that’s set at the initial record creation and updated when an invited participant signs up. Are there any cases where this isn't accurate?

(3) We are setting the following two variables for the success case: •Reinvitation campaign type (280021666): invitation type (from the same campaign type list as the initial invitation). •Reinvitation timestamp (439351436). I have no questions about this one. •Is that it, or am I missing anything?

Process (Please comment/correct/add to these if necessary):

1. Site sends reinvitation update with token, reinvitation campaign type, and ? (possibly other data for verification).
2. We search for the existing record, verify it is eligible for reinvitation (it has not been assigned), and add the reinvitation type and reinvitation timestamp CIDs (280021666 & 439351436).
3. We return success/failure based on the result of the operation.

@mnataraj92 can you address these questions re how and what vars sites will send using the updateParticipantData API when they send the re-invitation campaign type response?

[robertsamm]

Slight wrinkle in this plan... Chicago started re-invitations last week. Amelia is sending them a message giving them guidance on how we plan to implement this and asking them to track re-invitation campaign type and date on their side for now.
However, since we are planning to autogenerate re-invitation date d_439351436, theirs will be incorrect if they batch push us the re-inv campaign type after the March release.
Suggestions? Would we ask them to push their date to overwrite our autogenerated date?

Hi @brotzmanmj,

Perhaps the most straightforward approach would be a one-time function to process the updates for anything prior to this release. If they could provide a spreadsheet with token, 280021666, and 439351436 for each invitation record, that update would be straightforward to write and process.

I think we'd want to put most of the burden back on UChicago. We could open the API for a set limited time for UChicago to overwrite the date timestamp with the one they have recorded in their system (similarly to how HP and SH recently overwrote the recruit type date to correct it for those batches of recruits last week).

[JoeArmani]

Thanks @robertsamm. In that case, I do have a question about the timestamp (439351436):

When I'm adding functionality to this API, I like to keep validation as tight as reasonably possible to control incoming data quality. Based on the initial description, it looks like we'll generate that timestamp on the back end as the request comes in.

I would typically set this part of the API to disallow submission of 439351436 since we generate this variable.

We could temporarily allow the submission of 439351436 to coincide with your suggestion, and the logic for the check would be:
-- if 439351436 is sent and valid, use it (UChicago case).
-- if 439351436 is sent and invalid, reject the request (failure case).
-- otherwise, generate 439351436 (typical case).

We would potentially want another update to remove that UChicago logic if we go this route.

[robertsamm]

I think it would be just a one time send by UC, yes. Since @anthonypetersen has done something similar for the correction of the recruit type date data it might make more sense for him to check the logic above?

[JoeArmani]

@robertsamm, @anthonypetersen just walked me through your recommended process since I haven't been involved with these changes before. We'll limit it to the typical case and temporarily open the API in coordination with UChicago. Thanks for this recommendation.

[mnataraj92]

Hi @robertsamm,
I have a few questions about this addition to the updateParticipantData API:
Questions: (1) Will sites only send the token and re-invitation campaign type, or will they also send studyId or PIN for additional validation?
(2) It seems like we can validate: Recruitment type (512820379) = Not active (180583933) since that’s set at the initial record creation and updated when an invited participant signs up. Are there any cases where this isn't accurate?
(3) We are setting the following two variables for the success case: •Reinvitation campaign type (280021666): invitation type (from the same campaign type list as the initial invitation). •Reinvitation timestamp (439351436). I have no questions about this one. •Is that it, or am I missing anything?
Process (Please comment/correct/add to these if necessary):

1. Site sends reinvitation update with token, reinvitation campaign type, and ? (possibly other data for verification).
2. We search for the existing record, verify it is eligible for reinvitation (it has not been assigned), and add the reinvitation type and reinvitation timestamp CIDs (280021666 & 439351436).
3. We return success/failure based on the result of the operation.

@mnataraj92 can you address these questions re how and what vars sites will send using the updateParticipantData API when they send the re-invitation campaign type response?

Spoke with @FrogGirl1123 here are the responses!

Questions:
(1) Will sites only send the token and re-invitation campaign type, or will they also send studyId or PIN for additional validation?
Sites just need to send the token and re-invitation campaign type. The same token for each re-invited recruit should be used. Sites should NOT push us a new record for the same person in the system and sites should NOT send us de-identified data again.

(2) It seems like we can validate: Recruitment type (512820379) = Not active (180583933) since that’s set at the initial record creation and updated when an invited participant signs up. Are there any cases where this isn't accurate?
Recruit type should be not active until deidentified data is sent for an invited recruit and then they become active. Recruit type for those being re-invited should be active (as they were made active during the last invite).

(3) We are setting the following two variables for the success case: •Reinvitation campaign type (280021666): invitation type (from the same campaign type list as the initial invitation). •Reinvitation timestamp (439351436). I have no questions about this one.
Sites are sending us the re-invitation campaign type variable (280021666). The Re-invitation date (439351436) is being autoset by our system.

[JoeArmani]

Hi @mnataraj92,

Just so I'm clear on initial participant invitations:
(1) the shell record is created in the getToken API, and status is 'not active'.
(2) Then the status set to 'active' when the unidentified data is pushed and the participant is invited?

...And that's why status will be active for reinvited participants? I wasn't familiar with that second step, so I wanted to confirm. Thanks!

[hullingsag]

@hullingsag please work w/ Nicole to identify someone from Analytics to coordinate with KPCO and HFH to test this in dev and stage as Madhuri will be OOO

Assigning @BrittanyCrawford405 to handle data testing

[mnataraj92]

Hi @mnataraj92,

Just so I'm clear on initial participant invitations: (1) the shell record is created in the getToken API, and status is 'not active'. (2) Then the status set to 'active' when the unidentified data is pushed and the participant is invited?

...And that's why status will be active for reinvited participants? I wasn't familiar with that second step, so I wanted to confirm. Thanks!

Yep- status will be active for reinvited participants because their status would have gone from not active to active when they were invited to the study the first time & deidentified data was pushed.