Re: [Gnumed-devel] Comments on 0.2: storing degrees of certainty ("qualifiers")

[Karsten Hilbert]

Hello Dr. Midgley,

many thanks for your input. I have followed the recent
discussion on openhealth/openEHR about certainty/qualifiers.
It turned out that this may be rather hard to get right in
practice. Hence we constrain ourselves to giving the
clinician a tool to express her assessment of the situation
rather than objectively labelling the data quality.

So, the clinician can decide: yes, I believe this allergy to
exist in the patient or, no, this is just a suspicion but
let's stay aware of it anyway.

> I'm interested to see that there is effectively a field for each
> qualifier that may be invented for each stored item and that they are
> Boolean.
Well, in allergies there is: There's one field "definite"
that can be true or false and there there's one "type" which
can be either of allergy or sensitivity. It is record *who*
made the decision as well as by when and by whom it was
changed or deleted.

As for documents and lab results we have the fields
is_technically_abnormal and clinically_relevant (per
provider per record, not once per record). The lab result
additionally has a field for what the lab thinks about this
particular value.

> An alternative approach which has found favour, although Read Codes V3
> for instance has barely staggered into production use a long time after
> the discussion was going on, is to store a qualifier from a list.  One
> can end up over-normalised, but it means a change in qualifiers is
> accomplished by a change in data rather than database structure or
> program code.
Program code may still be affected to accomodate for the new
qualifier but, indeed, using a foreign keyed approach will
eventually prove beneficial. Should this part of the
database ever need expansion in terms of *degree* of
certainty we'll switch to a foreign key. It is easy enough
to do.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346