[DSEW CPR] Verify that naat_pct_positive is in fact a percent or rename to rate

[dshemetov]

The signal covid_naat_pct_positive_7dav comes from the column "NAAT positivity rate - last 7 days (may be an underestimate due to delayed reporting)".

[nmdefries]

This signal is a percent reported as a decimal, with values falling between 0 and 0.95. We usually report percentages on a 0-100 scale. I'm not sure if we should change the name to "rate" or multiply all the old values by 100. This source and signal are no longer active, so any fix would be a one-time change to the database.

[carlynvandyke]

seems like a % to me

[nmdefries]

I think this is still a problem (reported as a decimal, between 0 and 1, but should be between 0 and 100).

@aysim319 could you take a look at this? Should be a one-time patch, although seems like we might need/want to change this in the DB directly. Please check with Minh or Brian about doing that.

[aysim319]

It's still a problem, the default behavior of pd.read_excel is to convert percent datatypes into decimals....
I looked over the code and I think it'd be alot of effort trying to patch it while maintaining the issue dates, I think it's better to change it directly in the DB

[melange396]

This is a very old signal at this point and its been inactive for quite some time. Im not sure what the implications for changing it would be, like if its been referenced in papers or if theres some published code that expects it to be out of 1 instead of out of 100. The signal documentation sheet correctly identifies this signal as a "fraction"-type "format" though it has "percentage" as its "value label"... Perhaps we just update that and add a note in its documentation that points out the mismatch?

[nmdefries]

This is a very old signal at this point and its been inactive for quite some time.

Yeah, that's fair. I don't think this is the highest priority, I've been thinking of it more like cleanup. For the sake of consistency and not being confusing, I would somewhat prefer to change the name or value-format of the signal, but just noting it in the documentation would be fine.

I think it depends on how fast/easy/dangerous y'all think this is to do in the DB.

[melange396]

Changing the name:

• fast: very
• dangerous: minimally

Changing the values:

• fast: unknown (but shouldnt take absurdly long)
• dangerous: potentially (but low probability)

Both should be fairly easy. I would argue that changing the name (so the previous incorrectly named signal is no longer available) is more correct than keeping the old name but changing the value, plis it will be a faster and safer operation. Regardless of which change we make (name, values, or neither), the documentation definitely should explain the situation and history of the signal.