Open cusackjm opened 2 months ago
Module 4 range checks are updated in the Qx documents
Module 3 range checks are updated in the Qx documents
Module 2 range checks are updated in the Qx documents
Sorry- we have to update the range checks to a different formula. Please put all of this on hold.
Noted, thanks.
@boyd-mj Range checks have been updated in the Baseline Modules 1-4 questionnaire documents and are ready for programming. Let me know if you have any questions
@cusackjm is RcrtUP_YOB_v1r0 coming from other system like age?
yes, similar to how age was pulled
Thanks. And is it always going to be present? Or is it an optional question?
RcrtUP_YOB_v1r0 comes from the User Profile that participants complete when they sign up
I mean, while coding do I need to check if the value if present or will it always be present?
@joshid-ims the value will always be present
Ok, thanks!
SrvMRE_FirstPeriodAge_v1r0 - where is it coming from?
I am not sure if we can add conditionals in min max range checks.
@anthonypetersen @Davinkjohnson @cusackjm
Not sure if this can be implemented:
[RANGE CHECK min= SrvSAS_AgeCigsUseF_v1r0 IF SrvSAS_AgeCigsUseF_v1r0 HAS A RESPONSE, or min= 0 if SrvSAS_AgeCigsUseF_v1r0 IS NULL, max= (Current year - RcrtUP_YOB_v1r0 +1)]
number entered at MENSHIS
@cusackjm, the document has question IDs that do not have Srv... and such. So it is very confusing for me as I am not sure what they are as the code does not have them and neither does the document. That could be the issue in my above mentioned issue for range check conditionals too.
Are the Srv..and such added in the document by mistake or is it intentional?
I am working on Module 3 currently.
Same with instructions in Module 4.
they're from the user profile (which has a different suffix), not a survey (Srv). It's intentional and not an issue
I am asking about IDs like SrvMRE_FirstPeriodAge_v1r0. For e.g. in Module 2 document and in code, I do not see such IDs but instructions have them and I am not sure which ID it is.
Does the code work if the markdown has some variables programmed as variable names and others programmed as Old Connect Values?
That would be a question for Kirk. I will check with Kirk about the Transformation software. The Variable Names in the coding instructions do cause an issue in our workflow. The coders don't currently see the data dictionary. They rely on the Questionnaire. For questions already coded with Quest IDs, all instructions in the Questionnaire that might refer to them, would need to use Quest IDs. Otherwise, this is a discussion for Marie Joseph and Jen because it is a procedure change that will add additional time to coding.
Deepti and I had a discussion with Kirk. The transformer is only fed the JSON and the Mark-up and looks for Quest IDs to update them with the associated CID from the JSON. To create Display logic that relies on from data saved under a Quest ID, when the code has a Variable Name would require that the Variable Names are the same in the JSON and the Markup and that they have the same CID as the former Quest ID. Kirk will be on the call tomorrow to answer any questions, but I think the biggest issue would be getting the JSON to know when to use the Quest ID and when to use the Variable Name. I would like to make this our first issue to discuss tomorrow so that Kirk can jump off the call when we are finished with him.
Module 1 range checks are updated in the Qx documents