Hi! Good points from both of you, I just want to add a thought.
When designing or locally adapting GUIs I think it can be valuable to have the option to use radio-buttons (or widgets with similar visibility and semantics) also for DV_CODED_TEXT items if you know that the number of options are small and will suitably fit on screen. That will increase the up-front visibility of options and save time during data entry compared to opening and selecting from a combobox (or some other widget with similar interaction semantics). So having a GUI-directive/hint for suggesting radio-button interaction style for some DV_CODED_TEXT fields might actually be a good and useful thing. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Wed, Feb 2, 2011 at 04:27, Diego Bosc? <yampeku at gmail.com> wrote: > Is much different to change the field from 'test > result:positive/negative' to 'test result positive:true/false'? > If the semantics if not the same then the 'positive/negative' has more > meaning that a simple boolean and I think they should be coded > > 2011/2/2 Koray Atalag <k.atalag at auckland.ac.nz>: >> Hi All, I?d like to get feedback on this issue before we move on with >> implementing. >> >> In short whether we should use DV_BOOLEAN to represent the result of a Lab >> test as Positive/Negative. This particular test can have only two values >> (well plus the null case of course). I suspect this wasn?t the purpose of >> this data type in the first place and was for really no-brainer yes/no items >> as you would expect in any computer program. But, as ever, clinical medicine >> is wicked and makes me think out of the ?usual? good practice and explore >> whether this might be an option?Perhaps this discussion will provide >> guidance for others in the community as well. >> >> Secondly (assuming that we can use DV_BOOLEAN for such cases) in GUI not all >> occurrences of Boolean will have labels as Yes/No?It can also be True/False, >> Present/Absent, Positive/Negative etc. Moreover in difference language >> translations they will surely be different. But in ADL no at code is given >> for this data type; Yes and No is written implicitly within the definition >> section. This means that we cannot set the Text in ontology section and then >> have language translations. Has anyone come across such a requirement? If so >> what?s your solution. >> >> Note that I currently model all such data items with DV_CODED_TEXT and had >> no problems. But when I wanted to render radio buttons for Yes/No type items >> instead of default combobox widget I either need a GUI directive (which we >> try to avoid if possible) or set the data type to DV_BOOLEAN so that the >> default widget would be radio button and we can use accordingly. >> >> Cheers, >> >> >> >> -koray >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
