# Representing binary values with DV_BOOLEAN **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2011-02-02 03:09 UTC **Views:** 3 **Replies:** 25 **URL:** https://discourse.openehr.org/t/representing-binary-values-with-dv-boolean/15041 --- ## Post #1 by @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 --- ## Post #2 by @yampeku 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 --- ## Post #3 by @system 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 --- ## Post #4 by @Koray_Atalag 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 --- ## Post #5 by @Fabiane_Bizinella_Na 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 --- ## Post #6 by @yampeku That seems a clear 'null flavour' use case --- ## Post #7 by @thomas.beale 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. --- ## Post #8 by @system > 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 --- ## Post #9 by @pablo 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. --- ## Post #10 by @system 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 --- ## Post #11 by @pablo 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. --- ## Post #12 by @Derek_Meyer 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 --- ## Post #13 by @thomas.beale certain kinds of questionnaires are constructed with (some) purely boolean questions as well. - thomas --- ## Post #14 by @Koray_Atalag 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 --- ## Post #15 by @pablo 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. --- ## Post #16 by @system 2011/2/9 pablo pazos <[pazospablo@hotmail.com](mailto: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). --- ## Post #17 by @thomas.beale 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 --- ## Post #18 by @ian.mcnicoll 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 --- ## Post #19 by @ian.mcnicoll 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 --- ## Post #20 by @Stef_Verlinden1 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 --- ## Post #21 by @rjsearle All, I'd like to offer a view on this topic. While I have an, as yet, brief involvement into this field of health informatics, I have been involved in 'informatics' outside of health for many years, although that term is not used much outside of healthcare it is a very similar practice. So I'd like to inject some thinking from 'outside' into this conversation. I seek your forgiveness in advance if I make some newbie faux pas --- ## Post #22 by @SEABURY_Tom_NHS_DIGI Hi Thomas, At the point you state ‘we can't prevent medical researchers from creating questionnaires with purely boolean answers‘ I recognised a critical distinction, it is one we know quite well: The distinction between how data entry/review elements are built into clinical applications – the front end design – and the abstract model which these interfaces must map to. Taking the idea of a clinical researcher developing some informatics product – then they would ideally (re)use an abstract model (with its bound reference terminology) without re-modelling any of that, but then develop whatever screen designs then need, and merely define what on-screen values map to which things in the abstract model. I don’t think this distinction is contentious, but I think it is often assumed rather than stated. I guess there are few if any points in a full abstract model of medicine or healthcare more generally where the careful attention to an abstract model design would lead to the use of Boolean values. Ian McNichol’s contribution is useful here, putting this question into the context of prior work on clinical statement patterns. Tom Seabury --- ## Post #23 by @ricardo.jc.correia In my opinion this discussion is somewhat related with the existence of default values. A checkbox has typically one default value (either true or false). I am not really sure if storing a default value is the same as storing an user selected one. The idea of having 3 values (yes, no, null-flavoured) seems much more semantically rich and correct. I guess the null-flavoured can then be divided in "unknown to the user", "not applicable", "not yet answered by the user", ... I would also to add the difference between the doctor actually knowing the patient as particular condition (e.g. allergy to penicillin), or the patient claiming to the doctor he is allergic to penicillin. And so a simple checkbox of allergy to penicillin could become a set of options. [X] Allergy to penicillin VS (o) Patient says he is allergic to penicillin ( ) Patient says he is NOT allergic to penicillin ( ) Doctor says the patient is allergic to penicillin ( ) Doctor says the patient is NOT allergic to penicillin ( ) Unknown Of course, this would for sure have bad implications regarding the size of forms and time to fill them. Ricardo Cruz-Correia --- ## Post #24 by @Stef_Verlinden1 And it's to simplistic too. In that case one also would like to know allergic to which specific type(s) and/or components of penicillin. In that case I also would like to know how that was tested, when and who did that etc., etc. So I guess what's I'm trying to say is: What's the value of such forms and should we discuss this at this level? I guess that doctors always will keep using local forms for all sorts of purposes and at their own responsibility but I don't think we should try to standardize these form as well. I we're able to record the symptoms/abnormalities/functions found or exluded, by whom using which method it's up to the person who has access to that data how to interpret it and to evaluate if he/she can draw a conclusion based on his/ her standards. Like I said earlier an diagnose RA from hospital A can be a different disease from the one meant by the diagnose RA from hospital B and unless I have access to the underlying data I can't and won't use the the diagnose. Cheers, Stef --- ## Post #25 by @system Hi\! > 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\. Unless you reduce that mapping pain by having nice GUI\-hints/directives with documented semantics that you can use \(primarily in templates\) to indicate that this DV\_CODED\_TEXT should be presented as a radio\-button\-style group or checkbox \(possibly with default\)\. Good GUI\-hints combined with logic machinery could also be used to open follow\-up questions if desired as previously discussed in the thread named "Re: GUI\-directives/hints again \(Was: Developing usable GUIs\)" where on Mon, Dec 20, 2010 at 13:05, Erik Sundvall --- ## Post #26 by @ian.mcnicoll Hi Stef, I would probably disagree with you philosophically about the need to absolutely verify the provenance of any clinical assertion\. Whilst this might be desirable, I am not sure it is acheivable and we will be relying on trusting colleagues 'opinions' for some time to come\. Nevertheless, I accept that there are definitely circumstances where the simple assertion "Allergic to penicillin', recorded in one setting will not be sufficient\(or too simplisitic\) for onwards processing in another setting e\.g to trigger decision support\. However I would still maintain that we want to record this assertion consistently, no matter the particular GUI configuration\. i\.e Even if "Allergic to penicillin" is insufficient for my use, I would still like to receive that partial information in a consistent, queryable fashion, accepting that in some circumstances Allergic to penicillin Y/N is a perfectly legitimate approach to data capture\. I am just digesting this recent paper by Alan Rector http://www.cs.man.ac.uk/~rector/papers/Whats-in-a-code/Whats-in-a-code-rector-corrected.pdf Where he makes the useful distinction between Clinical Findings and Clinical Observables This roughly equates to the SNOMED classes but is more abstract from Rector's paper --- **Canonical:** https://discourse.openehr.org/t/representing-binary-values-with-dv-boolean/15041 **Original content:** https://discourse.openehr.org/t/representing-binary-values-with-dv-boolean/15041