Number of Deaths Calculation

[Natalia Gonzalez]

The InMAP README file states this:
* Numbers of deaths attributable to PM_2.5 in each of the populations are obtained by defining an expression in the configuration file based on the variables `TotalPM25`, the population variable of interest, and the overall or population-specific mortality rate. For example, deaths among the total population could be calculated with the following entry in the configuration file: `TotalPopD = "(exp(log(1.078)/10 * TotalPM25) - 1) * TotalPop * AllCause / 100000"`. Numbers of deaths are measured in units of deaths/year.

I am confused, because it seems that the equation  `TotalPopD = "(exp(log(1.078)/10 * TotalPM25) - 1) * TotalPop * AllCause / 100000"` is calculating a new death rate rather than number of deaths. The units of TotalPop is [# of people] and AllCause is [deaths/100000 people] so TotalPop * AllCause = # of deaths. When you divide by 100,000 in the equation, it is once again in units of [deaths/100000 people]. Should the documentation instead say that this is the equation to get a new death rate a a consequence of the emissions inputted? To calculate how many deaths are caused as a consequence of the emissions inputted, wouldn't you need to do (TotalPop*TotalPopD) - (TotalPop*AllCause) = difference in # of deaths as a consequence of the emissions?

[Natalia Gonzalez]

In short, why the additional "/100000"?

[Chris Tessum]

The baseline mortality rate (the "AllCause" variable) is reported in deaths per 100000 people, so we divide by 100000 to make the units work out.

[Natalia Gonzalez]

Sorry Chris, it still isn't adding up for me. Wouldn't you want to multiply by 100,000 to get rid of the 100,000 in the denominator? (1/100000)/100000  = 1/(100000^2)

[Natalia Gonzalez]

Wrote it out on the back of an envelope. It seems you guys calculate #deaths/100000 people rather than just # of deaths per cell

[vkrm...@gmail.com]

think of it this way: 

(ignoring the exponential part...)

we know from the available/reported data that death per 100,000 persons = AllCause

=> death per 1 person = AllCause/100000

=> deaths per TotalPop = (AllCause/100000)*TotalPop

[Natalia Gonzalez]

Ahhh I see now. Thank you for breaking it down for me!

[Natalia Gonzalez]

Does anyone understand why "all cause" is used in death calculations for each race, instead of race-specific mortality rates? Here is \the snipbit from the example Config file:

TotalPopD = "(exp(log(1.078)/10 * TotalPM25) - 1) * TotalPop * allcause / 100000"
WhitNoLatD = "(exp(log(1.078)/10 * TotalPM25) - 1) * WhiteNoLat * allcause / 100000"
BlackD = "(exp(log(1.078)/10 * TotalPM25) - 1) * Black * allcause / 100000"
NativeD = "(exp(log(1.078)/10 * TotalPM25) - 1) * Native * allcause / 100000"
AsianD = "(exp(log(1.078)/10 * TotalPM25) - 1) * Asian * allcause / 100000"
LatinoD = "(exp(log(1.078)/10 * TotalPM25) - 1) * Latino * allcause / 100000"

[Anil Gogebakan]

These transformations are for translating concentration changes to deaths and then moving between years (if I am not mistaken population data was from 2005) and some population growth rate has been assumed across years. So only difference between races is how many of the people live in each cell from a specific ethnicity, so the remaining part of the formula would remain intact.

Best,

Anil

[Natalia Gonzalez]

I believe the census data is an average between 2005 and 2015, hence the name census2013blckgrp.shp. If I am doing this analysis for the year 2035, should I multiply all the population values by the ratio of the total population in census2013blckgrp.shp to the projected population in 2035?

[Anil Gogebakan]

Here: https://www.inmap.run/blog/2019/04/20/sr/ 

At point 2 it explains why these constants are around and what role they do play. Well, I never go ahead of the current time in my analysis and I have the data about the past and can recover the average growth rate and go back and forth in time. but forecasting the future requires a lot of assumptions about what these rates would be etc. As I never do forecasting I cannot comment on how you would go about forecasting 2035 numbers, but I am sure there should be some established methods to go further in time. 

Hope it helps,

Anil