374 | | ==== Qw |
| 374 | ==== Weakness One ==== |
| 375 | This is from the consent stage: |
| 376 | {{{ |
| 377 | <variable name="mode" valueType="text" entityType="Participant"> |
| 378 | <attributes> |
| 379 | <attribute name="stage" valueType="text">Consent</attribute> |
| 380 | </attributes> |
| 381 | <categories> |
| 382 | <category name="ELECTRONIC"/> |
| 383 | <category name="MANUAL"/> |
| 384 | </categories> |
| 385 | </variable> |
| 386 | }}} |
| 387 | Most categories are much more complicated than the above, particularly in a questionnaire stage, where they spawn a lower variable (like tobacco_any.N in the !RiskFactorQuestionnaire where the N is described within the previous tobacco_any variable as a Category). But the above choices (ELECTRONIC and MANUAL) are a bit like stand alone enumerations. At present for categories this simple, the choices are being overlooked and are not collected, which represents a loss of information.[[BR]] |
| 388 | I suggest we collect this type of information by creating a lower level construct. I'm not sure what to call it, but I'm not concerned about the name provided its not misleading. What about <enum>? We can always change our minds later. |