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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
