dhis2-users team mailing list archive

[Tran Chau <tran.hispvietnam@xxxxxxxxx>]

Dear all,

Sorry about the later response.

The validation-rule for date fields is used for checking an inputted
date in data entry form. Before single event program occurs, the date
values are in range [ due-date ] and [ due-date +  Maximum number of days
allowed to input data] ( which is defined when creating a new program
). And currently, this rule isn't longer consistent.

Besides, the *Maximum number of days allowed to input data* is used for
creating activity plans in mobile project.

So as discussed ( with Ola, Lars, Bharath, John ), some things are changed
as follows :

A. Removed all *date validation* related to due date and *added new
features to validation rules* for data elements with type Date.


B. Created *9 rules* for date data elements as follows:


1. Before current-date

2. Before or equals to current-date

3. After current-date

4. After  or equals to current-date


The current-date is the lastest date we enter data value.


5. Before due date

6. Before or equals to due date

7. After due date

8. After  or equals to due date


9. Range  [ due date -/+ the number of days ( which users define for each
rule ) ]


Please click *Define program validation managenent* icon, and find the
validation with name "*Validation for date date elements*", click on the *
edit *icon to set validation for date-elements in each program-stage.

C. Renamed "*Maximum number of days allowed to input data"*  in Add/Update
program form to "*Date range for activities**".*

Please take a look at it :)

Best regards,
------------------------------------------------
Châu Thu Trân
HISP Viet Nam
Email: tran.hispvietnam@xxxxxxxxx


On Sat, Jan 14, 2012 at 2:04 AM, Mark Spohr <mhspohr@xxxxxxxxx> wrote:

> Ola,
> Sorry for the delay in responding to this subject but life was busy over
> the past few weeks.
> Thanks for taking the time to explore these issues and come up with a plan.
> We are not using this section (yet) but may in the future.
> I agree with your conclusions about removing some date checks since they
> can lead to problems in data entry.  In general, I think it is best to
> relax date restrictions except for clear, unambiguous cases since they can
> have unintended consequences for data entry.  In some cases, data entry may
> take place much later than the service date.
>
> One other issue about dates which is a problem with many medical records
> is that often the date is not known precisely.  Birth dates are notoriously
> inaccurate.  Many people do not know their birth dates.  Also, dates of LMP
> are usually approximate and dates of prior pregnancies are usually
> approximate.  In these cases, it would be good to not use a date type
> variable since that forces a level of precision which is not present in the
> original data.  I have seen people enter birth dates where only a year or
> month is known all as 1 Jan of the year or the first of the month.  This
> leads to all kinds of odd unintended consequences.
> I was wondering if would be possible to have a standard method to handle
> approximate dates of birth, LMP, etc.  where one could enter only a year or
> only a year and month if that was the best information available.  This
> "approximate date" would be more accurate and would avoid some oddities in
> data analysis.  However, it would be more complex to program and analyze.
>
> All the best for the new year and thank you all for the great work you are
> doing.
>
> Mark
>
> On Thu, Jan 5, 2012 at 10:22 AM, Ola Hodne Titlestad <olati@xxxxxxxxxx>wrote:
>
>> 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>
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-users
>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-users
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Mark Spohr, MD
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>