Mouthwash Overhaul Print Labels (Biospecimen)

[Davinkjohnson]

(High priority)

Current Process:
(1) Query pulls ALL participants where:

-not withdrawn

-not deceased

-no active refusals

-baseline blood/urine collectied = true

-time more recent than 04/01/02024

-add five day delay

(2) Then, it filters out participants where a mouthwash specimen exists (173836415.266600170.319972665)

Proposed change:

(1) Apply a kitStatus: initialized value to the participant profile based on the existing conditions when a specimen’s entry is finalized in the Biospecimen collection entry form (check all the current conditions and apply the status when conditions align).

(2) On the ‘Print Labels’ screen, we can use Firestore’s .count() query for labels to print. This counts as one read per 1000 documents instead of one read per document. We can query the specific participant data, ordered and limited, based on the number entered in the ‘labels to print’ input field. With this flow, we can simply query for participants whose kit status is ‘initialized’ and order based on the desired condition.

(3) Update status based on successful CSV generation.

-Note: the current process only gives one shot for those CSV files (I think). We should check whether that has been an issue — has there been any data loss on the BPTL side?

Note: This will require retroactive handling with a cloud function at prod release: Identify currently eligible participants in the ‘labels to print’ queue’ and assign kitStatus: initialized to these participants. We may have to monitor for crossover issues with collection sites running cached versions of the biospecimen app for the first 1-2 weeks (like we saw when Streck tubes were added).

Note: For future duplicate kit handling, it’s probably most effective to have a separate query for duplicate kits that gets merged into normal kit results. That way, we can prioritize the duplicate kits where needed. For example, if we’re printing 25 labels with 6 duplicates to handle that have priority, we can route the system to query 6 duplicates and 19 regular records.

-Lastly, it would benefit from code documentation and cleanup for future developers (this is non-essential)

@amber-emmes Check with @erincschwartz and @wyattks for their perspective, but I'm guessing this should be priority for Oct.

[erincschwartz]

In response to the note above:

-Note: the current process only gives one shot for those CSV files (I think). We should check whether that has been an issue — has there been any data loss on the BPTL side?

It is correct that the Print Address CSV file is only available 1x. This has not presented an issue to date for BPTL. Adding @wyattks here. Do you think we need this functionality changed at all? We wouldn't want BPTL to be able to generate the file again once additional participants have become eligible for address printing, I could see that leading to serious confusion.

Also, as discussed via chat with @amber-emmes, the "Query pulls ALL participants where:" list above should say AND Collection setting = clinical where highlighted below.

[wyattks]

Correct. It hasn't been an issue and I'm not sure if there is a way to have it print more than 1x without confusion. BPTL saves the files when they print in a secure loction incae they need to go back to it.

[mnataraj92]

Concept ID for 'initialized' response for Kit Status: 728267588

221592017 Kit Status

517216441 0 = Pending
728267588 1 = Initialized
849527480 2 = Address printed
241974920 3 = Assigned
277438316 4 = Shipped
375535639 5 = Received