Dear guys,
I need to calculate a program indicator for HIV program. The indicator is about patients who eligible for VL test. The conditions for this is long and complicated, so we created a DE called Next VL test, value is pre-calculated. The idea is that if a patient has their next VL test within reporting period, they are eligible for VL test.
PI setup:
aggregation type: count
analytics type: enrollment
boundary: custom using Next VL date (for both after start and before end of reporting period)
expression: tei count
However, the program indicator result is only correct for the future period. When i run the PI, the value for 2025 is correct, but value for 2024 is not. How do i get the PI to work in past period?
Since the 2025 are correct and 2024 aren’t, one possible explanation is because 2025 aggregate period isn’t complete yet so my assumption is when 2025 is over, the results will be incorrect as well.
Would it be possible to get a screenshot of the Analytics period boundaries settings in the PI configuration?
The 2025 is correct, i think because the PI using the latest event of VL test of the tei regardless of the boundaries, since 2025 is future period and hasn’t had any event yet. This cause the issue of not correct result in past period, when the VL events are not the latest.
The VL test event records a test the patient has done, include their test date, result and next appointment date for VL test (Next VL date). This program stage is also used to record other tests, so not all events have Next VL test, only event with VL results have Next VL test.
This is a great question. In enrollment type PI, the latest value of a data element in a repeated program stage is evaluated.
In your definition, as I understand it, you want to count the number of unique patients who had at least one “Next VL date” value during the reporting period. This value exists in a repeated program stage. So as you say, today the latest values for this data element in most enrollments would be 2025 dates, thus the 2025 count is correct while 2024 count are incorrect.
The Tracker design guide has a table with the order by which different PI parameters are evaluated
Evaluation
Component
Commentary
1
Organisation Unit
For event type it is the org unit of the event. For enrollment type it is enrollment org unit, even if some events in an enrollment were entered elsewhere.
2
Period
Defined by analytics period boundaries. Depending on the PI type, it defaults to the enrollment date or event date falling between start and end of the reporting period.
3
Filter
Create a value filter for the event or enrollment. Include tracked entity instance attribute values, or any data elements within a specific program stage (event type), or any data elements within any program stages. A variety of functions and variables are available for additional operations, like filtering for TEIs where the number of years between the enrollment date and the date of birth is more than 18.
4
Expression
The criteria above define which enrollments (or event) to include. The expression is the value that is applied to each enrollment (or event). Usually it will be event_count, enrollment_count, or tei_count, but can also be a data element value or more complex expression.
5
Aggregation Type
How to aggregate up the expression applied to each enrollment (or event). Usually “count” or “average”.
You can see that “period” is evaluated before “filter”.
What I would recommend is first using the period boundaries to restrict to all VL test events where “Next VL date” DE value could fall within the analytics period. This depends on your program rules, but lets say thats 6-12 months.
PS: we have some similar PIs in the HIV Case surveillance metadata package, that also use custom period boundaries as you have… but these evaluate the date each patient was first eligible for DS ART. The date of first eligibility is copied over from previous events via program rule. So not quite your use case.
Hi @brian
I tested your method, while the new PI gave a higher result compares to what i did before, its still nowhere near the correct result. For example, I tested for the new PI for Q1 2024, the PI gave 36, but event report gave 153. We are using ver. 2.40.5
Count all enrollments where any value for next VL date in the 12 month period prior to the start of the reporting period, and up to the end of the reporting period, falls within the start and end of the reporting period.
The query make take time to load as it scans all events to meet this condition, so check Data Exchange to copy these values to aggregate data elements. I havent been able to check this for validity.
If this does not work, I suggest you use your previous PI config, but go with analytics type: event. With expression: tei count, this will count unique persons with a valid event at the org unit and period of the analytics request. Note that, as discussed in the docs cited above, this may lead to double counting of individuals, if a patient meets the condition twice in the year at visits in two different facilities, and you make a facility-level analytics request.
Because the rules for Next VL date are so complicated, there will be a non-standard spacing between event date and Next VL date. So count events may be the best way to go, unfortunately… or exporting the tracker data, calculating unique enrollment VL dates with a different tool, and re-importing.
Update: I tried that earlier filter in my last message and it didnt work – I think if() will not accept a nested d2:daysBetween subexpression within it. There are other d2:countIfValue() conditions but those will not count be able to filter that an enrollment’s Next VL date was within the period.
