Hi,
This started out as a bug report, but ended being too long and included so many different bugs so I decided to start here, and then we can copy-paste to one or multiple bug reports later, if we agree…
So all this related to DHIS tracker, or what is called Name based data entry (under Services):
If I am not wrong there seems to be at least two different ways the values of the dates are validated, in addition to the type of course:
A) Date registered vs due date for the program stage instance.
The way I understand this is that the data cannot be reported before the consultation/visit is meant to take place. Data for a ANC Month 7 visit cannot be reported 2 months after the start of the pregnancy (5 months before the due date of the Month 7 visit). Similarly for Child Immunisation, the data for the 9 months after birth control cannot be reported into DHIS 6 months after birth.
B) Date registered vs program start + the program’s “Maximum number of days allowed to input data”.
This rule is more tricky, and I think is meant to block data entry too long after the beneficiary is meant to have finalised the program.
E.g. ANC should not take much more than 9 months, and Child Health Programs maybe not more than 5 years etc.
We allow some delay in data entry, but not too much.
(Personally, after trying to figure out this rule for some time now, I think we should remove it completely. More arguments for that below.)
After playing around with data entry in Tracker today there seems to be issues with the way both of these rules are used. I list them here:
- One big issue as I see it is that we are checking all dates registered in the form (also for data elements) against these two rules. In stead we should only check the Report date, which is metadata about the data in the form saying when the data was registered on to DHIS. So any data element with value type Date that is assigned to the program stage in question is checked against these rules. While the report date can say something about the date the service was provided, at least give us a proxy date, we cannot assume that the dates for any generic data element in a program stage actually relates to the date of the service. What if a data element is called “Date of your first pregnancy”, or “Your mother’s birthday” or whatever. My point is that data element’s are generic so we cannot check their dates against the rules A and B above. This is just too hard-coded to one specific set of forms.
If these rules are to make any sense, then we should maybe add a new metadata field for the program stage called “Date of Service”, which is actually what we want to check. That will allow delays in data entry, since report date can be much later if the data is first registered on paper. Report data is the actual date given to the patient data values, e.g. used in aggregation, but that date can in some cases be much later than the actual date of the service/visit.
- Another big issue, and perhaps the most important here is that the rules A and B above do not fit particularly well with the new type of patient “datasets” or program stages that are supported in 2.6 and in the pipeline for later releases. Single events, which is now supported to not have a due date as such, and therefore it makes no sense to check rule A.
Actually since all the dates in the form are checked, as explained above, this causes a funny bug for death registration where the Date of Death is one data element assigned to the “program stage”. Since due date is the same as reported date (the date when the death was registered) only deaths into the future can be registered. Any previous date (and most deaths are in the past…) will be blocked by rule A with DHIS saying “Date inputed <= Due date”. This can be tried on the demo.
For another typical use case of the more routine programs like HIV and TB where the program is not time-bound, but where controls/check-ups are repeated routinely, rule B makes no sense at all. There will never be a fixed or time-bound stop to the program enrolment, so the Program property of “Maximum number of days allowed to input data” makes no sense and should not be mandatory, and probably be removed completely.
So I suggest we simply remove these checks, both A and B. Right now these date input constraints are just confusing and messing up the system.
- Smaller issue. When inputting a date for e.g BCG dose given in Child Health Program for Stage Birth Details on the demo I cannot enter dates that are earlier than the due date. This makes sense since the due date is set to date of birth (registered at program enrolment). But the message displayed is confusing:
“Date inputed >= Due date”. It should rather say something like". I think it is supposed to say “Date inputed < Due date”, although I would prefer “earlier than” to the less than when it comes to dates. If we remove the date validation this bug obviously goes away. It is just one more thing that adds to the confusion around these date validations.
Anyway this is actually a good example where some kind of date validation makes sense, but it could maybe be implemented as a validation rule between two data elements “Birth date” and “BCG dose received date” in stead of this Due date thing.
So if people agree with me that we should remove the general date validation rules A and B above, then we should think of how we can provide validation of dates for the use cases where it makes sense. Some ideas:
i) Maybe it makes sense for some programs like ANC or Child Immunisation to put some time limit on the dates, since we know that the data for a pregnant woman should not not receive services much later than 9 months after the start of the pregnancy. Then we first of all need to find out what the date of the service/visit is, since that is the only date that it makes sense to check. This could be an optional property of a program stage instance, not sure.
ii) For dates for values of individual data elements what to check for will completely depend on the meaning of the data element. The data element could ask for a date in the past, a date in the future, or which is the most likely the date a specific service (e.g. a dose of Measles) was given. But since we cannot assume that all data elements are the same, we need to come up with a more custom way of defining this validation. Maybe some kind of validation rule specific to data elements with value type Date, e.g. “Must be earlier than the current date”.
Any thoughts on this? Hope this was not too confusing, it took me some time to get through this jungle of terms, rules, and messages in this module.
It is all just too confusing and not very user-friendly at the moment I am afraid.
Ola
···
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo
Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link