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. -- 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 From: sam.he...@oceaninformatics.com To: openehr-technical at openehr.org Subject: RE: Representing binary values with DV_BOOLEAN Date: Wed, 9 Feb 2011 11:54:49 +0930 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 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Koray Atalag Sent: Wednesday, 2 February 2011 12:40 PM To: For openEHR technical discussions Subject: 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 _______________________________________________ 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/20110209/7918c6c0/attachment.html>
