/Philosophical issues/ We have to be very careful with what can be modelled using Booleans and what cannot be. If a lab is returning results whose values (the values they provide, not you, the receiver!) can include Positive/Negative/Indeterminate, this is not a boolean situation, it is probably a coded term situation, particularly if you want to represent faithfully what the lab sent in the result. If however the panel item is marked in some way as 'not tested', 'not available' etc, it is a null-flavour situation.
Null flavour is used whenever the datum could not be / was not obtained. A machine that outputs answers like 'indeterminate' or 'trace' _is_ providing a value, because its algorithm is working on what was supplied to it. If however, the sample could not be processed at all, e.g. spoiled specimen, then the algorithm won't be applied. However, a smarter machine might also be able to detect spoiled specimens. So the philosophical problem is knowing what the model of reasoning is within the relevant lab machine. Obviously people other than lab technicians and pathologists would know that, so it may be an academic point. I would say that DV_BOOLEAN could only be used for answers to questions that can only ever have 2 answers (apart from 'didn't answer' etc, which is handled with flavour of null). It is up to the designer of the questions to decide this. For example, the question 'have you ever been pregnant?' could have the answers in Dr A's questionnaire of 'yes/no' (Dr A will put 'No' if the patient says they don't know). Dr B might allow yes/no/don't know, and simply record the three possible answers of the patient. Maybe the question was meant to be 'have you ever had a baby?'. Miscarriages would muddy the answer up here as well, so maybe it should be refined to 'have you ever had a baby that survived?'. And so on... The important thing is what computing will then be done with the data. Knowing this will determine the proper design of the question. If DV_BOOLEAN is used, what is put on the screen has to come from the question. This might be inferrable from the name, which might be at0021: 'ever pregnant', but is more likely to require an ELEMENT of its own carrying a proper linguistic rendering of the question 'have you ever previously been pregnant, to your knowledge?'. The at-code of this ELEMENT could be at0022: 'previous pregnancy question'. /The GUI / practical issues.../ I would steer clear of trying to directly infer the GUI control to use from the archetype on its own. Clearly some other rules are needed. For example Fabiane points out in her response that for <= 5 options, use radio buttons. This is some kind of rule needed in a rule-base - the archetype cannot possibly be used to infer it. Even if there was a GUI directive artefact available in the archetype environment, this kind of style rule still won't be found there (although exceptions might be marked in some way), so there is no escaping a set of global style rules in my view. - thomas On 02/02/2011 03:09, Koray Atalag wrote: > > 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. > * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110202/3445d84f/attachment.html>
