Representing binary values with DV_BOOLEAN

Technical (archive)
1

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

2

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

3

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@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

4

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

5

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

6

That seems a clear 'null flavour' use case

7

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.

8

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@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

9

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.

10

Hi

The issue needs to be discussed first in the modelling of the archetype. If a Boolean is accepted at this level then that is what it is (for the moment) and how that is displayed on the screen then becomes an issue. I agree that positive/negative != True/False. ‘Test Positive’ could have a true/false as in Test result abnormal in HL7 lab tests.

Fabiane’s idea that a Boolean defaults to false seems to be an implementation issue – it is possible to have a tri-state Y/N/Null widget to cope with the null.

This is a worthwhile discussion.

Cheers, Sam

11

Once, a professor told me: in healthcare there is no boolean data, you need at least three values, because there must be a registry of the data that is not recorded (like a null value), the item is there (the ocurrence of the node is 1), but the value is null. The data that is not recorded could have medico/legal value/semantics.

Of course, you may need something to know why the data was not recorded, like a “null flavour”, something like: I did’t ask, the patient don’t want to tell me, the patient don’t have the information, the patient can’t ask, etc.

Personally I don’t see much use of the DvBoolean alone.

12

Hi

The issue needs to be discussed first in the modelling of the archetype. If a Boolean is accepted at this level then that is what it is (for the moment) and how that is displayed on the screen then becomes an issue. I agree that positive/negative != True/False. ‘Test Positive’ could have a true/false as in Test result abnormal in HL7 lab tests.

Fabiane’s idea that a Boolean defaults to false seems to be an implementation issue – it is possible to have a tri-state Y/N/Null widget to cope with the null.

This is a worthwhile discussion.

Cheers, Sam

13

certain kinds of questionnaires are constructed with (some) purely boolean questions as well.

  • thomas
14

I kind of think that is the case and fully agree with your prof…at least 3-states. In fact I cannot understand why this hasn’t a big issue in other domains and have been ubiquitously used for many years everywhere.

Looking at the data structures and types RM since an ELEMENT with DV_BOOLEAN value will also have null_flavours attribute this 3-state requirement is met readily. I think the problem is using a 2-state checkbox or similar widget and binding any of the states to null. The widget also should have at least 3-states.

Cheers,

-koray

15

I agree with you Thomas but there’s always some implicit semantics, I mean: when there is no data, it is taken as false, but what happen if the person who do the questionnaire do not try to make this question false? May be he/her didn’t want to answer, and this false could have value/semantics in clinical or legal fields.

Just thinking out loud.

16

2011/2/9 pablo pazos <pazospablo@hotmail.com>

I mean: when there is no data, it is taken as false, but what happen if the person who do the questionnaire do not try to make this question false?

I do not agree with this. When there is no data, there is no data, neither true nor false. And the null flavour gives us the reason for that case. I think the DV_BOOLEAN is perfect as it is and if in some case it is not good for your needs, then you should use a different data type (a coded text for example).

17

Hi Pablo,

my point is that in some cases, researchers construct questionnaires for healthcare use that will have some purely boolean answers, and they simply won’t use responses containing missing answers, i.e. they will only use clean data. A question like ‘have you ever had children’ for example in such a questionnaire can be modelled as Boolean if the researcher wants simply to divide the population into two - women who gave birth, and women who never did. Any response like ‘don’t know’ would be discarded in such a study. I am not saying that this is good study design, or anything else (it isn’t my area), but we can’t prevent medical researchers from creating questionnaires with purely boolean answers, if that is what their statistical computing model requires.

  • thomas
18

Interesting discussion.

The big problem with DV_BOOLEAN is that it subverts the standard
'clinical statement model' used in current health informatics.

e.g The patient has diabetes (DV_CODED_TEXT) ) vs. Does the patient
have diabetes ? Y/N (DV_BOOLEAN).

This of course complicates looking for patient with diabetes, sine we
now have to run 2 different searches and the boolean variation may not
be able to take advantage of the inferencing in the terminology i.e
sub-types of diabetes.

The other problem is when desiging archetypes, what may seem like a
simple boolean, turns out to be a lot more complex when other clinical
groups are involved.

To take Derek's consent example. On the face of it, Consent Y/N seems
like a boolean but if you look at Snomed, there are at least 30 terms
below Consent status e.g. self consent, verbal consent for
examination. I found similar issues when modelling other clinical
findings

Blood in the urine Y/N in some data capture vs. Ordinal scales +,++
etc etc in others.

This starts to become very important when interoperating with other
clinical groups.

Null values are useful but often match poorly to the clinical terms
for a particular use case.

Negated questions are a further problem - what does Diabetes (no) mean
- are we asserting that the patient does not have diabetes or is the
negation just a way of ensuring that the question has actually been
asked. We do not normally capture negations in 'clinical statement'
stylwdata capture.

So !!!

Clinical questions are always going to be with us, and are certainly
easier to use when generating GUI but they have major issues with
interoperability and extensibility. My own ompinion is that we need to
look at some sort of clinical variation on DV_BOOLEAN, as Koray
suggested that allows the various True, False and null states to be
mapped/bound to term based equivalents, as Koray has already
suggested.

e.g.

Diabetes Y => Snomed Diabetes term
Diabetes N => Exclusion of Diabetes (or perhaps just boolean N).

This would have the advantage of allowing alignment with clinical
statements but make it easier for GUI designers to understand how to
represent the questionairre.

I very rarely now use DV_BOOLEAN when modelling but agree that using
DV_TEXT/CODE_TEXT is a pain to map to a checkbox/radiobutton GUI.

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

19

I should have added that this is not an openEHR issue but applies to
the whole of health informatics and would, IMO, make an excellent
subject for a PhD. We badly need the kind of academic analysis
equivalent to Alan Rector's work on the 'clinical statement' pattern
which underpins most of SNOMED, openEHR, 13606 and HL7 semantics.

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

20

To make thing even more complicated (we discussed this already some years ago) the question should be: Does the patient have diabetes according to the definition used commonly in this practice/ hospital/ county/ country/ part of the world.

Don't remember it exactly but back then I could easily find more than 4 different definitions of the disease/ syndrome called RA.

So maybe you search for DM patient should be 'diabetes Y/N' but 'symptom X present' AND 'blood glucose > Y' etc., etc. so that you find only those DM patients that comply to your locally used definition of DM.

This is also one of the bottle necks, would I blindly treat a DM patient who's diagnosed according to a different definition/ standard then I'm using? Probably not..... So whether it's a boolean or a coded_text the phrase DM Y doesn't mean much, unless I know the rest of the story as well. (I make the contrast a bit 'black and white' for discussion purposes)

Cheers,

Stef