Hi all,
if you are using the period types for tracker programs, we are interested in hearing from you here in the product management team. We are looking at this feature now and how to best facilitate the use cases that exists in the field.
There is both a “Expiry period type” on the program, and a “Period type” for program stages which can be set independently. We are interested to hear of your usage of either of these, as we want to clean up and potentially merge these period types.
I think that removing period types in Tracker stages will be a big mistake. The demo revolves only around medical data, but we use DHIS2 mainly for projects outside the health sphere and we have had different demands at implementation for the event dates.
Currently we have a client entering data in Tracker capture once every fiscal year (fiscal year starting July). So if you remove the fiscal years from the events and just leave an open calendar date there will be a lot of room for mistakes:
Data entry people will have to be instructed to choose a date = to the first day of the fiscal year.
I.e. fiscal year 2020 starts from 1 July 2019 and ends on 30 June 2020, so data entry folks will have to choose 1 July 2019. Then when you go to reports and aggregate data for fiscal year 2020 you have to actually aggregate by 2019.
Some people might accidentally omit step 1) above and actually leave the default date offered to a new event (which is the current date) and if this date is in 2020 then the fiscal year data will be in two yearly periods, thus impossible to aggregate for one fiscal year.
Same problems might emerge with any other period data entry that does not require an exact date - monthly, quarterly, and yearly.
Removing the period feature from the stage events will not improve the experience/functionality of DHIS2. On the contrary, it will depricate users of benefitting from periods of data entry that fit their specific projects. I am happy to jump on a call with you to further discuss this.
@Markus sorry for the late response. I have missed this duscussion.
I think that removing period types in Tracker stages will be a big mistake. The demo revolves only around medical data, but we use DHIS2 mainly for projects outside the health sphere and we have had different demands at implementation for the event dates.
Currently we have a client entering data in Tracker capture once every fiscal year (fiscal year starting July). So if you remove the fiscal years from the events and just leave an open calendar date there will be a lot of room for mistakes:
Data entry people will have to be instructed to choose a date = to the first day of the fiscal year.
I.e. fiscal year 2020 starts from 1 July 2019 and ends on 30 June 2020, so data entry folks will have to choose 1 July 2019. Then when you go to reports and aggregate data for fiscal year 2020 you have to actually aggregate by 2019.
Some people might accidentally omit step 1) above and actually leave the default date offered to a new event (which is the current date) and if this date is in 2020 then the fiscal year data will be in two yearly periods, thus impossible to aggregate for one fiscal year.
Same problems might emerge with any other period data entry that does not require an exact date - monthly, quarterly, and yearly.
Removing the period feature from the stage events will not improve the experience/functionality of DHIS2. On the contrary, it will depricate users of benefitting from periods of data entry that fit their specific projects. I am happy to jump on a call with you to further discuss this.
Hi there Georgi,
Thank you for the feedback. Trying to formulate your request as a user story, explaining the user, functionality and the rationale:
As a data entry clerk entering periodic survey results, I want the system to validate wether I have entered results for the current period already, to avoid making the mistake of entering several survey results on the same period.
Can you comment wether this user story seems to fit your use case? And can you think of additional users and concerns we need to cover?
Thanks for the response! Let me formulate it differently:
“As a program and data entry manager, I want to ensure that period selection in Tracker stage events is not confusing to data entry clerks, especially when data is collected once per year or once per fiscal year. For yearly or fiscal year data entry, I would like data entry staff to be able to select the period from a list of deliberate options, i.e. 2019, 2020 OR July 2019-June 2020, instead of choosing and open date from a calendar, which is prone to mistakes and requires extra care.”
Actually, I think that adding periods to Event capture would be really helpfull as well. We have many case in which data entry is done once per quarter or once per 6 months. Working in Event capture with an open date calendar, means that the data entry person needs to be carefully selecting the date, so that it falls within the quarter or the six-month period, whereas it would be much easier and less prone to mistakes if the Reporting date in Event capture was selected from a drop-down: Q1 2020, Q2 2020, etc.
Thanks for reading and considering al this!
Georgi
So in the use case you describe, there is a tracked entity instance, and the tracked entity instance has an enrollment with a stage that is collected in predefined periods. Could you give an example that I can add to your user story? What would be te actual data modeled in this way?
For single event use cases, one could ask wether it is better to use a data set that is collected with a given frequency?
Here is an example: We have an organization that works in multiple countries, implementing various projects (from improving everyday life, to empowering women, to reducing gender-based violence, etc.). In every country there is one or multiple teams collecting data about various projects once within a fiscal year (starting from 1 July and ending on 30 June).
The data model is as follows: Every project is a tracked entity instance with its attributes like Project focus, duration, budget, donors, etc. Each project has multiple, repeatable stages, which represent different areas/scores/data being collected about the specific project. A project may be on for 5+ years. Data entry people collect data within a fiscal year for a specific exisitng project AND register new projects as they appear. In this case, a data set will not do the job as we need the flexibility to register projects ad hoc and collect longitudinal data for them. Event capture won’t do it either, because there is a lot of project specific (attribute) data, that we don’t want reentered every year.
I have more examples for use cases like the one above. We have a client that enters budget data and season plans for all the events to be held within the next fiscal year. The fiscal year again flows into two calendar years, so it is much easier, safer and more user friendly if data entry people could select a fiscal year for the Tracker events they create, as opposed to choosing from an open period. This organization uses DHIS2 as a planning tool. They are entering a schedule for all future events that are to occur within the current/upcoming fiscal year. They have an odd fiscal year period (1st Sept - 31 Aug), so we were unable to accomodate it for data collection and reporting and had to work around it.
Actually, I think that (and I have had many cases in which I wished this was available) DHIS2 should provide the possibilty for users to build their own periods/fiscal years for data collection and reporting. This should be encoded somewhere in the system settings where a user can select all the months that fall within their fiscal year and be able to label that period. That would have been very useful for the case with the organization that uses 1st September as a starting fiscal year date (as per the example above).
Sorry if my explanation is a bit messy. Let me know if you need more clarification.