gnumed-devel
[Top][All Lists]

Re: [Gnumed-devel] Measurement conversion concepts

 From: Busser, Jim Subject: Re: [Gnumed-devel] Measurement conversion concepts Date: Sun, 1 Dec 2013 19:34:51 +0000

```Further on this, I was wondering about the method of lookup / linkage to a
conversion table… I gather these involve

public.basic_unit (name_short, name_long)
public.unit (fk, name_short, name_long, factor, shift)

Is it intended that

public.basic_unit involves only these:

http://www.unc.edu/~rowlett/units/sifundam.html

?? and what of things like prefix handling?

Here are some scenarios:

(1) involving shift -- I can think only of Fahrenheit and Celsius which would,
in public.unit (not ref?) be

(fk to F)       C       Celsius 1.8     32

(fk to C)       F       Fahrenheit      0.55    -32

but noting that while the first conversion depends on a natural order of
operations

C ---> F = C x 1.8 + 32

going the other way, one must do

F ---> C = (F - 32) x 0.55 requiring parentheses

i.e. they are not symmetric. This case maybe has to be individually provided
for in whatever is the converting function. Is this an isolated case, or is
anyone aware of any other biological measurements that involve (require) a
shift?

(2) general cases where the measurements are what I will call "substrate
independent", for example in expressing a length … in the following example of
row population, I have omitted long names:

(fk to cm)      m       100     0
(fk to cm)      mm      0.1     0
(fk to cm)      in      2.54    0
(fk to cm)      ft      30.48   0

… these can all share the same conversion factors without any need for each of

test_type.conversion_unit (where name = height)
test_type.conversion_unit (where name = abdominal circumference)
test_type.conversion_unit (where name = aortic aneurism dimension)

but do we require multiple sets of such rows, one set of 4 values where we
rotate in

public.basic_unit in {mm, cm, m, in, ft) keyed from a set of 4 rows in
public.unit {one row each for the other 4 among mm, cm, m, in, ft}

??

and also do we need each item in public.basic_unit to *also* appear in
public_unit with a conversion of 1 ("unity")?

(3) in the case of derived units, consider

hemoglobin (mg / dL --> g/L)

… should there be a value in public.basic_unit

g/L

with matching values in public.unit {g/L, mg/dL}

… or should each component in the expression

mg and dL

have to resolve to components in public.basic_unit

mg to g
dL to L

and then be multiplied through by the component factors?

(4) what about when the units in question are substrate-dependent and involving
things like molecular weights and valences

mg/dL vs umol/L Calcium vs 1 mEq

http://sitemaker.umich.edu/tutorial/files/handout_milliequiv.pdf
http://www.unc.edu/~rowlett/units/index.html

-- JIm

```