ucum-org / ucum

https://ucum.org
Other
58 stars 10 forks source link

Pack-year #57

Open timbrisc opened 14 years ago

timbrisc commented 14 years ago

Issue migrated from trac ticket # 52

component: help | priority: major

2010-08-19 21:22:36: gschadow@pragmaticdata.com created the issue


From Victoria Johnsson:

Dear Professor Gunther Schadow,

In my work I use Unified Code for Units of Measures (UCUM) for standardizing units in various clinical datasets. It works very well for most units in clinical data.

I noticed however that the UCUM specification does not mention the unit pack-year which is used to measure how much a patient has smoked.

Number of Pack Years = (Packs smoked per day) x (years as a smoker).

How do I specify this unit according to UCUM? Am I allowed to define it as a unit atom, [pack-year]?

I would be very grateful if you could help me. Thank you!

timbrisc commented 14 years ago

2010-08-19 21:49:34: gschadow@pragmaticdata.com commented


Dimension: T^-1^ x T, meaning "pack year" is a dimensionless unit.

A "pack" is an object, not a unit. Of course, one may estimate a pack as about 20 cigarettes, but that is not always true, so there is no good fixed conversion between pack and cigarettes. Also, pack-year seems to be the only conventional quantification of smoking behavior, not cigarette-day. So conversion between pack and cigarette seems not required. In that case, pack is not a quantitative concept and can be disregarded (dimensionless count number, unit = 1).

Consequently, the smoking frequency is a normal frequency, dimension T^-1^. Unit for "packs smoked per day" would be "/d". One can of course write "{pack}/d" but that curly brace is not adding any semantics.

The multiplication with the smoking duration (dimension T) means that the resulting number is proportional to the estimated total number of packets smoked. Specifically a "pack-year" is 1/365.25^th^ of the total number of packs smoked. Because of this, the dimension of what is called "pack year" is truly 1, i.e., this quantity is dimensionless, it is simply a count noun.

Note that "pack year" appears to be a misnomer. Compare with the pre-existing analogous term "light year" and "man hour". "Light year" is the distance that light travels in one year. "Man hour" is the amount of effort a person would do in an hour. In that sense, "pack year" should be the amount of smoking-effects that a pack induces in a year. This, of course, is not what is meant. Perhaps a more systematically adequate name would be the "pack-a-day year", i.e., the amount of smoking-effects that a pack-a-day of smoking induces in a year.

This is not a unit and should not be added. Instead the meaning should be entirely in the definition of the quantity concept, i.e., if the quantity is defined as "estimated total amount smoked" and the measurement method defined as "estimated number of packs smoked per day multiplied with the estimated number of years smoked", then the quantity value can be specified as the simple dimensionless number.

Adding units into this term would confuse more than it would help. Because if a person has smoking frequency of 2 packs per day (f # 2 /d) and smokes for 10 years (t10 a) then the product of f t would be 20 a/d # 20 365.25720.50 instead of just 20, as the users would expect. On the other hand, from this, one might define the unit "pack year" as 1 a/d, which then would allow the result of 2 /d * 10 a to be written as 20 a/d or 20 [pack'year].

So, have I now talked myself into accepting such a unit? Comments from others would be needed. I do not like this unit, but it could be defined as

1 [pack'year] = 1 a/d.

But before this is done, need to check if there isn't also a "cigarette year", which would then need to be defined commensurable but different from pack'year.

timbrisc commented 14 years ago

2010-08-23 08:34:09: werner.keil@gmx.net commented


At least according to Stephen Colebourne (Spec Lead of JSR-310/Joda) he wouldn't consider that one "major", but I leave it up to others to judge.

Based on the Unit-API, UOMo allows combinations of existing (UCUM/SI) units so there a new custom SystemOfUnits with such specialized unit types was easy. I would however leave this to Grahame's UCUM part.

timbrisc commented 14 years ago

2010-08-29 18:58:45: gschadow@pragmaticdata.com commented


But we are not talking about "custom system-of-units" here. UCUM has only one system of units. We have recently improved a bit on how to deal with arbitrary units. But the discussion on this particular unit proposal should be held specific. Thanks.

timbrisc commented 13 years ago

2011-07-26 19:03:14: gschadow@pragmaticdata.com changed status from new to reject_proposed

timbrisc commented 3 years ago

2021-01-15 21:07:14: mitchbre@regenstrief.org changed status from reject_proposed to new

timbrisc commented 3 years ago

2021-01-15 21:07:14: mitchbre@regenstrief.org set component to help

timbrisc commented 3 years ago

2021-01-15 21:07:14: mitchbre@regenstrief.org edited the issue description

timbrisc commented 3 years ago

2021-01-15 21:07:35: mitchbre@regenstrief.org changed status from new to assigned

timbrisc commented 3 years ago

2021-01-15 21:07:35: mitchbre@regenstrief.org set owner to cjmcdonald

timbrisc commented 3 years ago

2021-02-17 17:49:33: mitchbre@regenstrief.org commented


Note from Clem

Maybe could Could express it as {Pack}.A for pack years But think it desrves square bracket defininont eg [pack.years]

timbrisc commented 2 years ago

From Marjorie: https://www.cancer.gov/publications/dictionaries/cancer-terms/def/pack-year