Date validation in Tracker data entry - problematic and confusing

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.

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

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

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

···

On 5 January 2012 18:21, Ola Hodne Titlestad olati@ifi.uio.no 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 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.

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

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

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@ifi.uio.no wrote:

On 5 January 2012 18:21, Ola Hodne Titlestad olati@ifi.uio.no 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.

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

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


Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-users

More help : https://help.launchpad.net/ListHelp


Mark Spohr, MD

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
  1. Before or equals to current-date
  1. After current-date
  1. After or equals to current-date

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

  1. Before due date
  1. Before or equals to due date
  1. After due date
  1. After or equals to due date
  1. 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 :slight_smile:

Best regards,

···

Châu Thu Trân
HISP Viet Nam
Email: tran.hispvietnam@gmail.com

On Sat, Jan 14, 2012 at 2:04 AM, Mark Spohr mhspohr@gmail.com 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@ifi.uio.no wrote:

On 5 January 2012 18:21, Ola Hodne Titlestad olati@ifi.uio.no 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.

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

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


Mailing list: https://launchpad.net/~dhis2-users

Post to : dhis2-users@lists.launchpad.net

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@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp