Context
The roc_coverage function lets users calculate coverage by residence or occurrence. To do this, it asks for three data sources:
- EIR
- Vaccination schedule
- Population denominators
The reason for requesting the EIR is obvious: you need it to calculate the amount of doses applied. So is requesting the population: the function needs it to calculate coverage. But, the reason for requesting the vaccination schedule might remain unclear. Here is the explanation:
The roc_coverage function calculates coverage by year for each vaccine. Given that vaccines are administered at different ages, the function needs to know the schedule so that it can use the correct population for each vaccine.
For example, when calculating coverage for DTPCV1 (which is applied at 2 months) for doses applied in 2023, the function reads the schedule and knows that the population denominator to use are those children with age 0 in 2023. But, when calculating coverage for MMR1 (which is applied at 12 months) for the same year, the function reads the schedule and knows that it must use the children with age 1 in 2023.
In summary, the vaccination schedule is a way of communicating which denominator to use when calculating coverage.
Problem statement
However, the current method might still be confusing, because users must provide a population database that contains the amount of individuals of ages 0, 1, 2, etc... for each year.
For example, if we want to calculate residence/occurrence coverage for DTPCV1 and MMR1 in 2022 and 2023, here is the table that users must provide. Plus, this can be extracted more directly from an electronic civil registry.
| year |
age |
population |
| 2022 |
0 |
45846 |
| 2022 |
1 |
48268 |
| 2023 |
0 |
45445 |
| 2023 |
1 |
47828 |
Proposal
The usage could be clearer for users if we instead ask for a population database containing population per cohort, and then, pahoabc could extract the necessary denominators for each vaccine.
The table that users provide would look like this, which contains one row less because it only provides population by cohort.
| year_cohort |
population |
| 2021 |
48268 |
| 2022 |
47828 |
| 2023 |
45445 |
Context
The
roc_coveragefunction lets users calculate coverage by residence or occurrence. To do this, it asks for three data sources:The reason for requesting the EIR is obvious: you need it to calculate the amount of doses applied. So is requesting the population: the function needs it to calculate coverage. But, the reason for requesting the vaccination schedule might remain unclear. Here is the explanation:
The
roc_coveragefunction calculates coverage by year for each vaccine. Given that vaccines are administered at different ages, the function needs to know the schedule so that it can use the correct population for each vaccine.For example, when calculating coverage for DTPCV1 (which is applied at 2 months) for doses applied in 2023, the function reads the schedule and knows that the population denominator to use are those children with age 0 in 2023. But, when calculating coverage for MMR1 (which is applied at 12 months) for the same year, the function reads the schedule and knows that it must use the children with age 1 in 2023.
In summary, the vaccination schedule is a way of communicating which denominator to use when calculating coverage.
Problem statement
However, the current method might still be confusing, because users must provide a population database that contains the amount of individuals of ages 0, 1, 2, etc... for each year.
For example, if we want to calculate residence/occurrence coverage for DTPCV1 and MMR1 in 2022 and 2023, here is the table that users must provide. Plus, this can be extracted more directly from an electronic civil registry.
Proposal
The usage could be clearer for users if we instead ask for a population database containing population per cohort, and then,
pahoabccould extract the necessary denominators for each vaccine.The table that users provide would look like this, which contains one row less because it only provides population by cohort.