Representing binary values with DV_BOOLEAN
Hi Diego, thanks for your points... I agree that changing data item to 'Test X result Positive: True|False' is the right way to use Boolean data type...But while this is an elegant technical approach it has problems in two ways (in my opinion): 1) From modelling point of view the non-techy domain experts may find this type of thinking and hence naming of data items difficult. The straightforward way of modelling would be to insert a node with text corresponding to the screen label (i.e. Test X) and then put values positive|negative. It would be implicit to clinicians that these values actually are "Result" of the Text X. 2) This representation also when it comes to automatic GUI generation will be quite problematic as the generator needs to know how to represent the correct semantics on the form. In this case I would assume we'd need a GUI directive perhaps stating how to render this correctly on screen. So in our example it has to: a) Extract data item name from Text of archetype node (i.e. Test X). Actually it is not possible to deduce this if the naming is done with some convention (i.e. Test XRest of the name; like 'Test X<%> result positive' b) Get labels for values from GUI directive (i.e. DirectiveA (labels:positive|negative). Or use the Description property of at code to insert these (i.e. using a custom syntax) c) Put a label with text from (a) on form d) Put widgets for values: - in our case two radio buttons with labels positive and negative or simply (+) and (-). - Alternatively a combobox with these two entries. - Or two radio buttons with captions positive and negative - Or kind of precoordination; merge label and value and display two radio buttons with labels Urease(+) and Urease(-). Perhaps in (d) a better way of displaying this node (for reasons Eric has mentioned) might be to just put a single checkbox next to the label (i.e. Test X) and bind checked value to positive etc. In our case we are working on the Rapid Urease Test which is either positive and negative. I'd like to see on our GUI the label and a checkbox next to it. Simple... We are trying to come up with GUI directives which could handle all such alternative representations...Quite challenging but hopefully getting somewhere. Any thoughts? Cheers, -koray -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Diego Bosc? Sent: Wednesday, 2 February 2011 4:28 p.m. To: For openEHR technical discussions Subject: Re: Representing binary values with DV_BOOLEAN 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 : > 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
Representing binary values with DV_BOOLEAN
That seems a clear 'null flavour' use case 2011/2/2 Fabiane Bizinella Nardon : > > I came across this problem several times. It became almost impossible to use > DV_BOOLEAN. The worst problem is that since DV_BOOLEAN has to be always true > or false, if someone simply does not fill the field, it became immediately > "false", which almost always was not what the user wanted. > > The solution was to use a CODED_TEXT with 3 values (true, false, > blank/null). For the GUI part, if the CODED_TEXT had less than 5 options, it > was automatically rendered it as radio buttons and not combos. This avoided > GUI hints. Actually, this is a common and good human/computer interface > rule: use radio buttons if you have less than 5 options, render a combo if > you have more than 5 options. > > Fabiane > > > On 2/2/11 1:09 AM, 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. > > > > > > 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 > >
openEHR future directions
t couple of years, and the Jira trackers show a number of small but important change requests waiting to be done. These represent real maturity: such change requests are things that nobody could have guessed at the outset. So openEHR today provides a practical platform for health computing both on the tooling side and the EHR systems and messaging side. If this is seen as valuable, or can be turned into practical value, then the only problem is one of organising the community to support the ongoing work. Solving the three-headed Hydra problem may be the start. - thomas beale On 02/02/2011 15:30, Erik Sundvall wrote: > On Tue, Dec 21, 2010 at 17:44, Tony Shannon wrote: >> Please see the announcement below for your attention. >> Your views on the future direction of openEHR are especially important >> at this time. >> Please feedback any/all views to this list to generate the discussion we >> need. > Hi Tony! > > Thanks for inviting comments in an open way. Organisational issues > have been touched upon earlier (see previous discussions on the > technical list). I believe some of us would like to know what will > happen to the feedback this time. Some previous discussion responses > (and partly an interest in implementation rather than organisation) > have made me keep a version of this message in draft for several weeks > instead of finishing and sending it. My hope is that this message > helps more than it hurts. > > Previously parts of a board announcement said... > * * -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110202/460c9e09/attachment.html>
Representing binary values with DV_BOOLEAN
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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110202/3449cfa8/attachment.html>
Representing binary values with DV_BOOLEAN
Hi, I think the ideas under "points of improvement" here: http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates, for creating a GUI control library usable from GUI templates, may help on this subject. -- Kind regards, A/C Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > Date: Wed, 2 Feb 2011 14:59:02 +0100 > Subject: Re: Representing binary values with DV_BOOLEAN > From: erik.sundvall at liu.se > To: openehr-technical at openehr.org > > On Wed, Feb 2, 2011 at 13:32, Thomas Beale > wrote: > > The GUI / practical issues... > > I would steer clear of trying to directly infer the GUI control to use from > > the archetype on its own. > > I agree that most often such combobox vs radio-style hints would be > wrong at an archetype level. I was more thinking of usefulness of a > directive at a more local template level e.g. when wanting to ovveride > default framework behaviour. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > > 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. > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110202/b483f348/attachment.html>
Representing binary values with DV_BOOLEAN
On Wed, Feb 2, 2011 at 13:32, Thomas Beale wrote: > The GUI / practical issues... > I would steer clear of trying to directly infer the GUI control to use from > the archetype on its own. I agree that most often such combobox vs radio-style hints would be wrong at an archetype level. I was more thinking of usefulness of a directive at a more local template level e.g. when wanting to ovveride default framework behaviour. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > 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.
Representing binary values with DV_BOOLEAN
/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>
Representing binary values with DV_BOOLEAN
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 : > 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 > >
Representing binary values with DV_BOOLEAN
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? 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 : >> 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 >
Representing binary values with DV_BOOLEAN
I came across this problem several times. It became almost impossible to use DV_BOOLEAN. The worst problem is that since DV_BOOLEAN has to be always true or false, if someone simply does not fill the field, it became immediately "false", which almost always was not what the user wanted. The solution was to use a CODED_TEXT with 3 values (true, false, blank/null). For the GUI part, if the CODED_TEXT had less than 5 options, it was automatically rendered it as radio buttons and not combos. This avoided GUI hints. Actually, this is a common and good human/computer interface rule: use radio buttons if you have less than 5 options, render a combo if you have more than 5 options. Fabiane On 2/2/11 1:09 AM, 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. > > Cheers, > > -koray > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110202/14ec39b2/attachment.html>
