dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

On 5 January 2012 18:21, Ola Hodne Titlestad <olati@xxxxxxxxxx> wrote:

> 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 some more testing and playing around with the "Maximum number of days
allowed to input data" I have realised that the B rule is slightly
different from what I described above. The latest date allowed is actually
the program stage instance's Due date + the program's "Maximum number of
days allowed for data entry". You can test this by modifying the property
and then try to put in some future dates in data entry. This means that the
property is more like an allowed "delay" for each stage, and not a total
validity period for the whole program (e.g. 9 months after start of
pregnancy for ANC). Not sure why this is a program property then, if it is
just a general delay for each visit. It could be a system property in
stead. Or we could allow such a delay to be specified for each program
stage, if they should be different. After chatting with John today I got
the understanding that the intended behaviour was more like what I
described in my previous email, that the "Maximum number of days allowed to
input data" relates to the total period of the program, and not just an
accepted delay in service provision for each stage.

Anyway, this doesn't really change much, apart from adding some more
confusion maybe.

Ola
-----


> 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>
>