Douglas Carnall wrote:
>>In control systems, all values have an associated "data >>quality" marker, which, if it indicates that the value is "old" or that >>serial communication from the field has stopped, you ignore the actual >>value (which might otherwise look like a completely legitimate >>transformer voltage or whatever). In HL7, all their data types include >>the notion of Null values in every possible field, and the include a >>"flavour of null" - reason for why the value is not available - e.g.. >>"unknown", "unavailable", "not asked", "asked but refused", "not >>applicable" etc (that's from memory so the values might be a bit off). >> >The need for a language of uncertainty... interesting. Will think more about >this. > the HL7 ballot has the full explanation if you are interested. But there is a big difference in the we way apply it and the way they do. They specify that not only can a whole datum be Null (with its flavour of null stated), but any attribute thereof can as well. This means that you can get partially populated data items (e.g. a quantity with no units, an interval with missing limits etc) which I have argued is more complex to process, and more likely to result in software errors (given the quality of real world software). Theoretically, there is nothing wrong with their approach (in fact it's quite an interesting idea), but for the moment,we are going to go a simpler, more expected direction. Time and experience will tell whcih approach is more appropriate. >>>>2. Imprecise. (eg. age "between 25 and 30" etc.). This arises from >>>>a lack of granularity. >>>> >I often find, when I'm coding a consultation, that I am happy to use a precise >Clinical Term as a starting point for a statement of a diagnosis, but want to >qualify it in some way. Most commonly, I want to add "?" or "??" or "???", or >all three in a list of differential diagnoses of descending probability, or >utility. > >e.g. > >chest pain ?ischaemic ??muscular ???emotional > ok - at the moment, we would say that a differetnial diagnosis would be defiined by archetypes, which in your case would be associations of terms and confidence factors expressed as what we call DV_ORDINALs, giving you the ablity to just use "?", "??", "???". This means your software could be written to accept exactly what you have put in above. >Once the system has >been used, one important use for the data gathered in the uncertainty space >will be to enable a retrospective qualitative examination of the kinds of >qualifers that have been felt useful by clinicians, and attempt some taxonomy >for Version 2. > agree - we need some more in-use experience before further theorising... >>>>3. Vague. (eg. blood pressure "high", smokes "a lot", pain "acute", >>>>etc.) This arises from the use of fuzzy terms. >>>> >If the system could record a set of "imprecision preferences" for each >individual user, it could enable: >1) subsequent users of a vague value to get a feel for how the individual who >recorded it has used vague values in other instances; >2) individuals to compare their own use of vague values with others, and >migrate towards a mean. > what this means is actually using fuzzy quantitative mappings for imprecise terms. The fuzzy (numeric) data has to be carried with the symbolic datum each time, so it can be compared to other's data, and the comparison will work, even if your "high" is someone else's "critical". We haven't yet got this facility, but I think it is important enough to start designing into the archetype model. >Although you're right that your ordinal set is not the way I'd choose to >record smoking data myself, if another clinician chose to use that framework, >I could still draw useful inferences from it subsequently. > right. >There must be lots of data gathering designs out there on this topic; I think > > never?/ever?/now? are the main top heads for tobacco consumption; > > if never record null value > > if now=no but ever=yes > then offer opportunity to record start date, cessation date and > pack years > > if now=yes > then offer opportunity to record start date and daily > consumption > > (note, people don't always smoke the same amount each day) > >is the way I like it (and think about it) but others might find >implementations based on this irritating. So why not allow clinicians to have >a box in which they can either: > >1) just write text about tobacco consumption >2) set up their own structure that is meaningful for them (and share those >structures on the internet, like complicated config files are shared for >example, those of mutt or bash. > well, this is what archetypes are about. But we can go frther with them, since we can allow 2 or 3 alternative smoking archetypes, and computationally convert between them, but comparing their interfaces. This won't necessarily be easy, and in some cases will be very challenging (e.g. comparing numeric nr packets to "heavy smoker") but the principle is there.... >>Our idea wsith DV_ORDINAL was primarily not to prevent doctors from >>using "+", "++", "+++" type values, and to add a little bit of rigour >>(ensuring comparability). >> >Let's not inflict rigour on people. Let's offer clinicians delightful >opportunities to express what they thought, and what they mean. Comparison >should be a secondary function. > it's hidden in the model anyway - they won't see it. But it's useful for pseudo-standardised sets of symbols for e.g. urinalysis >>>>4. Uncertain. (eg. a 95% chance of accuracy). Arises from a lack >>>>of knowledge or subjective assessment. >>>> >>for this we include a "confidence: REAL" attribute in the ENTRY class. >> > >Err... I'm quite happy telling a patient that I'm 90% confident that it's just >a virus, but I'll see them next week if it's not settling down. I'm not so >sure that it'll be meaningful to make comparisons with my colleagues' >statements that they were 85% and 95% confident that the patients they saw >had viruses too. > >Just because you've got two numbers doesn't mean that you can perform >arithmetic with them. > this is true, but I'm not sure what the alternative, since at least a % is more neutral than "low", "med", "high". Is there any research in this area I wonder? >>>>6. Out-of-date. (ie. correct when stored by unlikely to be true now). >>>> >>this is a tricky one, and an example is "smoking status"=smoker which >>might be true up until two years ago, but change then. >> > >I'm much more relaxed about this. Clinicians are experts at interpreting old >data from clinical records. As long as I know that, at date X, clinician Y >thought Z was true, I can form a judgement about what that means, and what >action if any I need to take to refresh the data now. > right. I am right behind the idea that the EHR is to help clinicians do their job (which is a lot of the time: thinking, evaluating, deciding...) not try to take it over. Well leave it to Bill Gates and his paper clip to do that. >>Sam has been contemplating ways of representiing the idea of >>"confirming" previous information whose value does not change, but we >>want a more recent update on teh situation (and medico-legally, the >>practitioner wants to show in the record that they did indeed review >>various things on such-and-such a date). This might require a special >>marker whcih does not change the valuue of something, but says that it >>was verified to be the same. I don't think we have and answer yet for >>this in the architecture. >> > >Sort of like the Unix "touch" command? > that's it. thanks for the input. I think the two items for us to consider from this are: a) need for fuzzy quantification in archetypes to correspond to ordinal symbols (+, ++, +++, ?, ??, ??? etc) b) possible re-evaluation of % as a way of expressing subjective certainty. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
