You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Task DPC.TB.108B "Follow-up and linkage for positives" is one of the tasks that TB seasonality curve applies to. For Amhara region, with a low incidence of TB at 0.0011 (or 108.3 per 100,000 pop), the expected total annual Num_services is 3. While applying seasonality to this task, the total annual number was allocated to 12 months and then rounded, resulting 0 Num_services per month in the seasonality results. If we try to aggregate monthly results to annual, we could recover the original Service_time but not the original Num_services, because all the 0s would sum to 0.
The text was updated successfully, but these errors were encountered:
thanks @rhanIDM
We found this issue also through testing the seasonality for tasks
as you can see the attached 2 tasks (time series for Service_time)
108A has rate multiplier so the seasonality looks reasonable but 108B does not as the numbers are too small
I would propose that we not apply seasonality to any activity counts less than 60 (5 per month). If the activity count is less than 12, then we assign the integer counts randomly to months, but ignore seasonality.
Task DPC.TB.108B "Follow-up and linkage for positives" is one of the tasks that TB seasonality curve applies to. For Amhara region, with a low incidence of TB at 0.0011 (or 108.3 per 100,000 pop), the expected total annual Num_services is 3. While applying seasonality to this task, the total annual number was allocated to 12 months and then rounded, resulting 0 Num_services per month in the seasonality results. If we try to aggregate monthly results to annual, we could recover the original Service_time but not the original Num_services, because all the 0s would sum to 0.
The text was updated successfully, but these errors were encountered: