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 at 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 On 9 February 2011 17:18, David Moner <damoca at gmail.com> wrote: > > > 2011/2/9 pablo pazos <pazospablo at 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). > > > -- > David Moner Cano > Grupo de Inform?tica Biom?dica - IBIME > Instituto ITACA > http://www.ibime.upv.es > > Universidad Polit?cnica de Valencia (UPV) > Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta > Valencia ? 46022 (Espa?a) > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
