During development of the training, the usage of the isRequired and isEnabled option was not clear. This ticket is to propose a better explanation in the IG.
The following explanations were given by Richard and Dave via E-mail that could be used for the IG:
isRequired indicates whether a value for the property has to be obtained whenever the BC is used in the study. When isRequired is true, isEnabled must also be true so that you can obtain a value. You must obtain a value even if there is only one value to obtain – for supine vital signs, the position property must be enabled so that you can specify the response code of “supine”. How you implement this downstream is up to you – you can hardcode the position value in your EDC (in which case the define.xml Origin for SDTM VS.VSPOS would be “CRF”) or you can exclude position from EDC (but you would still represent the value in SDTM VS.VSPOS and indicate this with define.xml Original as “Protocol”).
isEnabled is really only relevant for properties where isRequired is false – isEnabled is used to indicate whether or not you’re going to obtain a value for the non-required property in your study (where “obtain” means either pre-specify a single value for the response code or collect which of the available response code options applies).
- isRequired is a definitional BC level item. Does the BC definition demand that this information is present within the data. Reflects the science behind the BC:
a. The test code … True, a BC would not be useful without it. This will always be a single coded value, no need to collect it, always fixed.
b. A method qualifier.
i. May be not required as we can just use the result and don’t care about the method used to record it … so False.
ii. If we defiantly do need the method to make sense of the data, then True
c. Labs and specimen, I would be cautious of a BC definition where it was set False, would be weird not to have a specimen collected for a labs (I’m sure they exist but …)
d. So, it is isRequired [by the BC science]
- Is Enabled is a study level use item:
a. Do I want to collect it in this particular study?
b. If it is required (the science demands I need it), I need to collect it. If it is not required, then I can choose.
c. So, it is isEnabled [within this study]
- As Richard said, "isEnabled is really only relevant for properties where isRequired is false”, IsRequired is at the top level, isEnabled is a secondary level item. Unfortunately, they sit at the same level in the class.
- isEnabled on the response code, allows for coded values to be fixed.
a. Body Position: Sitting, Standing, Supine. Defined within the BC definition
b. I may fix it to Supine (so Supine True, other two False), because I want Supine, it must be Supine. Science says all recordings must be supine.
c. If it could be any position and is collected, all True ... the medics don’t care what the position was, they just want the result, but they cannot bring themselves to not record the position 😊
d. This is Richard’s second email re define and “protocol” if fixed and the study design is telling us that this is fixed, hence driven by the protocol, or collected if all enabled and “collected"
e. So, again, it is isEnabled [within this study]
During development of the training, the usage of the isRequired and isEnabled option was not clear. This ticket is to propose a better explanation in the IG.
The following explanations were given by Richard and Dave via E-mail that could be used for the IG:
isRequired indicates whether a value for the property has to be obtained whenever the BC is used in the study. When isRequired is true, isEnabled must also be true so that you can obtain a value. You must obtain a value even if there is only one value to obtain – for supine vital signs, the position property must be enabled so that you can specify the response code of “supine”. How you implement this downstream is up to you – you can hardcode the position value in your EDC (in which case the define.xml Origin for SDTM VS.VSPOS would be “CRF”) or you can exclude position from EDC (but you would still represent the value in SDTM VS.VSPOS and indicate this with define.xml Original as “Protocol”).
isEnabled is really only relevant for properties where isRequired is false – isEnabled is used to indicate whether or not you’re going to obtain a value for the non-required property in your study (where “obtain” means either pre-specify a single value for the response code or collect which of the available response code options applies).
a. The test code … True, a BC would not be useful without it. This will always be a single coded value, no need to collect it, always fixed.
b. A method qualifier.
i. May be not required as we can just use the result and don’t care about the method used to record it … so False.
ii. If we defiantly do need the method to make sense of the data, then True
c. Labs and specimen, I would be cautious of a BC definition where it was set False, would be weird not to have a specimen collected for a labs (I’m sure they exist but …)
d. So, it is isRequired [by the BC science]
a. Do I want to collect it in this particular study?
b. If it is required (the science demands I need it), I need to collect it. If it is not required, then I can choose.
c. So, it is isEnabled [within this study]
a. Body Position: Sitting, Standing, Supine. Defined within the BC definition
b. I may fix it to Supine (so Supine True, other two False), because I want Supine, it must be Supine. Science says all recordings must be supine.
c. If it could be any position and is collected, all True ... the medics don’t care what the position was, they just want the result, but they cannot bring themselves to not record the position 😊
d. This is Richard’s second email re define and “protocol” if fixed and the study design is telling us that this is fixed, hence driven by the protocol, or collected if all enabled and “collected"
e. So, again, it is isEnabled [within this study]