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 Op 9 feb 2011, om 19:03 heeft Ian McNicoll het volgende geschreven: > 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 >> >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
