Rates per 100000

Deadline

New member
Joined
Oct 21, 2019
Messages
2
OK, so, I have a fairly complicated query to which the answer is possibly straightforward, but I can't see it so any help would be gratefully received. I work with data a lot, but Rates always give me problems. For some reason I just can't quite get my head around them in the same way as any other mathematical concept.

I have a set of data for which the rate per 100,000 appears to have been calculated incorrectly. I can see the problem and I can see what's been done, I just don't understand it. I can't include the data, or a sample of it as it's data obtained from behind a paywall, however I'll attempt to replicate it.

The data is for a single quarter (October to December), looks a bit like this:

PlaceNo. of Identified CasesTotal PopulationRate per 100k
Town 114226,4722,146
Town 220342,2541,922
Town 312228,5781,708

It actually reports on a weird lag, so October-Decembers data is being reported now and acts as the first quarter for this reporting period (it's a weird setup). The formula that was included with the dataset that has been used to work out the rate per 100K is this:

No. of Identified Cases/Total Population x 100,000

The problem is that using that formula gives different results than those on the official data. Town 1, for example, comes out to a rate per 100k of 536. Town 2 is 480 per 100k. Having played with the data, I've discovered that the given 'Rate per 100k' is actually exactly 4 times that of my calculation, which suggests that the data is being provisionally calculated for an entire 12 month period based on a single quarters figure.

Now, the data is reported in a cumulative manner, i.e. next quarters' data will cover January to March and will be reported as a sum of 2 quarters data. So if Jan-March identified cases is 150, the reported figure will be 292 (142+150).

However, doing this will increase the rate per 100k as the quarters progress and the number of identified cases increases because the population will remain at the same level.

My question is 2-fold:

1. Is it usual practice for a rate per 100k to be worked out in advance based on an initial entry?
2. Is it correct to calculate a new rate per 100k using cumulative data?

As I said, I just don't 'get' rates per... I understand the concept, I understand the formula, but for some reason the combination of the 2 just does not sit in my head correctly.
 
It is normal to ANNUALIZE data assuming some sort of projection for the entire year.

Evenly Spread throughout the year
1st quarter
142 of 26,472 ==> 536 RAW / 100k ==(x4)==> (2,146 / year)/100k

2nd quarter
142+150 of 26,472 ==> 1103 RAW / 100k ==(x2)==> (2,206 / year)/100k

3rd quarter
142+150+115 of 26,472 ==> 1537 RAW / 100k ==(x4/3)==> (2050 / year)/100k

These are just approximations for the entire year. After the 4th quarter, it is no longer an approximation. This is a reasonable thing to do for some budgeting mandates or procedures.


If it's about the flu, which we KNOW is very seasonal, it might look like this.

1st Quarter (Start of flu season): 142 Expected to be 35% of the annual total.
2nd Quarter (End of flu season): 150 45%
3rd Quarter (Break): 115 10%
4th Quarter (Break): 105 10%

142 / 0.35 = 405 ==> (1,533 / 100k) / year
(142+150) / 0.80 = 365 ==> (1,379 / 100k) / year
(142+150+115) / 0.90 = 452 ==> (1,708 / 100k) / year
(142+150+115+105) / 1.00 = 512 ==> (1,934 / 100k) / year

Given that this distribution was a little odd, and didn't really conform to the 35, 45, 10, 10 expected pattern (see below), one may wish to revise the quarterly expectations for the next year. Any rational pattern can be used.

142/512 = 27.7%
150/512 = 29.3%
115/512 = 22.5%
105/512 = 20.5%

One may not want to revise TOO MUCH given only a one-year anomaly.

Anyway, there are many things that can be done and many reasons to do them. Maybe your data are quarterly and your budget is annual, for example.
 
tkhunny, that makes total sense and is exactly what I needed, thank you!!

Nothing in the provided data explained why the rate had been worked out as it had, so I automatically assumed it was wrong but couldn't guarantee it, hence the post.
 
Top