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 X<some separator>Rest 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 <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
