Tracker capture: difference between enrollment date, incident date, due date and event date

Hi, everyone.

I have read some DHIS2 documentation, but I still can’t figure out the difference between enrollment date and incident date on programs; due date and event date on events. I have difficulty in configuring dates due to a lack of clear understanding of the difference between them.

Any explanation is welcome.

3 Likes

Hi Fernando,

Below is an extract from the MEASURE Evaluation guidance Using DHIS 2 Software to Track Prevention of Mother-to-Child Transmission of HIV. In this guidance, we’ve explained some of the key steps you need to think through when creating a Tracker, including the correct configuration of dates etc. (The Guidance relates to version 2.27, but the use of dates has remained the same - probably the only major change is that users can now change incident dates after enrolment as long as no events have been scheduled based on that date.)

The Importance of Dates in the Tracker

A number of different dates need to be configured when setting up a PMTCT Tracker, and it is worth carefully reviewing these before you create your programs and program stages. The terminology for dates is not always consistent in the DHIS 2 documentation, and dates are one of the most common areas of confusion encountered when configuring a DHIS 2 Tracker. This section provides an overview of the different dates used by the Tracker along with specific guidance on how to configure them for the PMTCT Tracker.

A program has two dates associated with it; both are important, because DHIS 2 uses them to restrict data entry and to calculate due dates and notifications:

  • Enrollment date: Although you can set this to be whatever you date choose (the label is configurable), it is usually the date in which the patient enrolled in the program of care.
  • Incident date: This is a key date in the patient’s pathway that you typically choose as the base date from which visit schedules and notifications are calculated. (There is also a setting that lets you use the enrollment date instead for these schedules and notifications.)

Note that both of these dates need to be entered when you enroll a patient into the program, and the dates cannot be changed once they are entered. [Limited changes are possible in later versions of DHIS2.] Both enrollment date and incident date can be used only for aspects of a program of care that are already known at the time of enrollment (e.g., “actual delivery date” would be appropriate as an incident date for a postnatal program of care but not for a PMTCT program of care, because it is not known at the time of enrollment in PMTCT).

The program stage does not have any dates associated with it.

Each event has two dates associated with it:

  • Due date: This is the future date on which an event should ideally occur; it can be automatically prompted by DHIS 2 (by setting the program stage’s “Scheduled days from start” or its “Standard interval days”), or it can be set by staff when they use the calendar icon in the patient dashboard to schedule a future appointment.
  • Event date : This is the date entered by staff (or sometimes automatically generated) to show when the event actually occurred. (In different parts of DHIS 2, this is also referred to as “Execution date” or the event’s “Report date.”)

If you schedule an event to happen in the future, then this upcoming event will have a due date, but it will not have an event date yet. After you convert the scheduled event or booking to an actual (completed) event or visit, an event date is also recorded for it. If you create an event or visit directly, without first scheduling it, then only the event date is important (the due date will still be populated with a default value, but it will be ignored by DHIS 2).

I hope this helps clarify Tracker dates for you - please let me know if you have any further questions.

8 Likes

Wow thanks a lot. Actually I am encountering the same problem. It really helped a lot.

1 Like

Thank you @SamuelJohnson. The difference is clear now. If any further questions, I will let you know.

1 Like

Hi @SamuelJohnson.

Sorry for bringing this topic that was posted three years ago

Regarding this text, the part about incident is not clear for me.

If I know beforehand the exact period of time that separates events, what would be the correct date date - incident or enrollment date - to use to schedule events?
e.g I know that the second event will happen 60 days after first event and the third event will happen 120 days after the second event.

Thanks.

Hi everyone,

What is the relation between incident date and event date? At registration we have two dates: enrollment date and incident date. It has never been clear to me the exact meaning of incident date.

Could you please mention some examples of when to use it?

Thanks

Hi @ferdinandmussavene can you read this topic?

1 Like

Thanks @asacur :pray:

Hi Hernandez,

Apologies, I’ve only just seen this now. Glad to see these old community threads are still useful to members!

In your case, it sounds like you could configure the appropriate dates in your program stages, rather than using the overall program’s enrollment date or incident date.

Put in really simple terms, the incident date (or, alternatively, the enrolment date) is about when you want your overall time-tracking for the program to start. It’s a single starting point from which you can schedule your events. If, however, you want events to happen a certain number of days after each other, then you can instead just schedule events based on previous events, rather than on a single starting point for the program.

I’ll give two examples:
ANC: here we may want to measure visits from the last menstrual period (LMP), not from each other - so we would schedule all events to be a specific number of days after the LMP. The reason this is important is that if the patient comes one month late for their 2nd ANC visit, we don’t want to also then delay their 3rd visit - we still want them to stick to the original schedule, and “catch up” for lost time. In this case, in the tracker we could schedule a series of different program stages, each using ‘scheduled days from start’ to select the number of days from the initial incident date (ie LMP).
ARV treatment: here we want to measure visits at a fixed distance from each other, not from an original starting date. The reason is that we issue 30 days or 90 days (plus some spare) of ARV medication each time the patient visits, so even if the patient comes a month late for a visit (ie they’ve missed medication), there’s no point trying to get them to “catch up” - we’ve given them 90 days of medication, so we just schedule the next event to be 90 days after the previous one. In this case, we don’t care what the original starting point for the program was, so we could ignore the incident (or enrolment) date and instead configure a single (repeatable) program stage, using ‘standard interval days’ to schedule each ARV visit a specific number of days after the previous event.

Your case sounds a little like the second example - you care more about the number of days since the previous event, rather than the number of days since the original date that the patient’s pathway started.

Cheers, Sam.

2 Likes