Re: [Gnumed-devel] clinician input wanted: how to implement "coding"

[Karsten Hilbert]

On Thu, Dec 03, 2009 at 02:27:58PM -0800, Jim Busser wrote:

> I was thinking about how we assess severity or risk or prognosis from data 
> and how coding may better enable that.

> The Body Mass Index (BMI) is derived from the patient's
> weight (in kilos) divided by the square of the height (in
> meters). For GNUmed to calculate this for us for any
> patient, we may want GNUmed to be able to:

> - locate for a patient, from in the measurements table, a
> weight (if one can be found)

That would be done by LOINC code and is already possible.

> but GNUmed also needs to
> determine if this weight is in kilos or other unit (pounds)

That is readily available in the
clin.v_test_results.val_unit field.

> and, if in pounds, convert it.

The conversion can be facilitated by
clin.test_type.conversion_unit.

> I cannot recall whether LOINC
> is so specific to also specify the units of measurement or
> if GNUmed would have to consult a "units" field.

It does but we would rather ignore it and keep ourselves to
the measurement stored with the individual value and only
consult test type level default units if no units are given.
In that case heuristics need to be applied to sanity check
the unit vs the value and also put up a notice to the user
(and store her decision on a unit for later benefit).

> - locate, for the patient, a height and resolving the same
> issues as to units (metres vs centimeters vs inches vs feet
> & inches)

see above

> - recognize that there exists more than one LOINC for
> certain measurements, for example weight coul dbe while NPO
> or else with or without clothes or maybe there are also some
> other kinds of weight

The BMI code needs to be aware of the multiple-LOINC possibility.

> - decide how to deal with the fact that a measurement
> could be "old" and therefore a BMI could be based on a
> combination of a weight that was two months old (because it
> was not measured at every visit) and a height that was from
> 2 years ago (because the height is documented even less
> often). Accordingly this "BMI" could be formatted so as to
> visually warn the user about the dates for example appending
> in parens the date of the most recent element and/or the
> oldest element

Yep, that's what I'd do: show the date of included results.

> - it might be desirable to graph the BMI over time (based on a series of 
> weights)

That is but an extension of the above with the one caveat
that height may be re-used if appropriate.

> - another good example would be cardiovascular risk scores
> which are based on a combination of age and sex and family
> history and blood pressure and laboratory measurements.
> However even if we would wish to "submit" these data to a
> calculator and query the result we would need a coded way to
> designate the sex which is not in all languages "M" and "F"
> and also the family history.

We already support one such calculator (despite the fact
that it does not yet have an interface for passing data -
which I stipulated be added): www.arriba-hausarzt.de

Our gender fields are already coded anyway. It is just a
coincidence that we use "m" for male and "f" for female -
those values are treated as codes at any rate inside GNUmed.

What you describe here are very valid clinical use cases.
That is also why we supported LOINC right from the beginning ;-)

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