Hi Team
Iam looking for a help for this use case.
scenario1: Beneficiary registered in Q4 of 2022, receives an event in Q1fy23 and q2fy23 - active
scenario2: Beneficiary registered in Q4 of 2022, receives an event in Q1fy23 and does not receive in Q2FY23 - inactive
scenario3 : Beneficiary enrolled in Q4 of 2022, does not receive an event in Q1fy23 and receives one in Q2FY23 - Inactive
scenario4 : Beneficiary registered in Q1 of 2023 does not receive an event in Q2FY23 - Inactive
Scenario 5: Beneficiary registered in Q2 of 2023 receives an event in Q2FY23 - active
Then a basic way to approach this is to have the condition expression: V{enrollment_count} and then the filter would be something such as V{enrollment_status} == ‘Active’ and the other program indicators can be either Completed or Cancelled. And it is possible to use various expressions in the filter for even more filtering.
@dguambe There are a range of options you can use to achieve your objective, however, it is best to adopt an approach which will require minimal maintenance. Depending on how your data entry forms are configured, you can easily achieve your objective using generic DHIS 2 functions or it could warrant using custom scripts which may be difficult to maintain over time
Use case for generic DHIS 2 function: Assuming all beneficiaries will have data captured for them each quarter, you can define two data elements: Received a service (Yes/No), Beneficiary active in the quarter (Yes/No). A program rule can then be used to determine participation status (active/inactive). The scenarios you listed can be built into the program rules that defines the participation status. Some complexities may be involved:
You may need to create some ‘intermediate’ data elements to store values for specific quarters, participation status for quarters and semester etc.
Program rules to copy over status from previous quarters and compare event dates to determine if they are within the same semester etc.
Usually, there are other participation status outside of active/inactive e.g. transfers and exits, you need to be able to account for them by either incorporating into the same data elements, or creating separate data element, complementary to the ones above, and either showed or hidden as needed.
Use case for complex data entry form or if data capture is not necessarily done quarterly: An example of a typical OVC program is briefly stated here. In one implementation, we used a script as a workaround to the inability to schedule events and populate them for specific periods and org units.
