-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IRONN-225 EMPRO month 12 expired vs. not available #4354
Conversation
…expired". Added comparison with consent to correct.
Realizing we'll need a migration to catch cached adherence data for the affected patients. |
Hello @pbugni! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2024-01-04 00:43:04 UTC |
… - believed this may be part of missing results from IRONN-222
portal/models/reporting.py
Outdated
# due to complex business rules around start or walked off | ||
# the end. Assume if consent + 1year > now, it's the former. | ||
consent = datetime.strptime(row["consent"], "%d-%b-%Y %H:%M:%S") | ||
if consent + timedelta(days=365) > as_of_date: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per https://promowiki.movember.com/pages/viewpage.action?pageId=72941826#SequencingofPROMs-EMPROQUESTIONNAIRE , the actual 12 month expiration date can be significantly later than this.
- "If the subject consents to the IRONMAN and EMPRO studies on the same day: the EMPRO questionnaire is made available for four weeks from the date the subject completes their baseline IRONMAN questionnaire". So, this cutoff date can be up to 4 weeks too early in this situation.
- "If the subject consents to the EMPRO study after consenting to the IRONMAN study... (and) If the subject consents to the EMPRO study more than four weeks after completing an IRONMAN questionnaire: The EMPRO questionnaires are made available for four weeks from the date the subject completes their next IRONMAN questionnaire" - this may be even longer than four weeks later, as I read it.
Am I reading this correctly? Would we report "Expired" to soon in these situations?
If so, can we look to the timeline for a more accurate date here? If not, we'll need to explain to PCCTC how to interpret this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, yes, you are correct. i'll need to work that in, thanks for remembering this detail @mcjustin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also of note, found in testing scenarios where row["consent"] == None
need to account for this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I read it, you've addressed this - thanks
…oesn't take that long to update, good to catch any problems with a re-calc on a more regular basis.
…nts. enables quick, small batch runs, and use from /timeline corrected an old bug in view lookup due to scope problem.
obtain adherence data if not already in cache on /timeline request
…et available didn't consider delayed start timing. use the user's timeline, only consider it expired if 12th month visit expiration has passed.
@mcjustin I just requested a fresh review after fixing the issue you found above. testing revealed other details i resolved as well. |
anything less than a day old, and expect them to still be in the cache.
fix for https://movember.atlassian.net/browse/IRONN-225
EMPRO qb_status expired status is ambiguous - can mean "not yet available" or "expired". Added comparison with consent to correct in adherence report.