dhis2-users team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

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:

1) 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.

2) 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.

3) 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<http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Vetlandsvn.+95B,+0685+Oslo,+Norway>