dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Hi All,

The following explains a bit more about surveillance rules and how they are
similar to, and different from, other validation rules. We might also
consider whether/how to distribute some of these ideas more widely. Some of
these ideas might go into future user documentation. We might also consider
putting some of this kind of information into a future topical DHIS forum,
if we want to explain things in more depth without making the user
documentation *too* huge. ;)

Cheers,
Jim

---------- Forwarded message ----------
From: Jim Grace <jimgrace@xxxxxxxxx>
Date: Wed, Nov 13, 2013 at 10:45 AM
Subject: Re: [Dhis2-devs] Surveillance validation rules
To: Jason Pickering <jason.p.pickering@xxxxxxxxx>


Hi Jason,

I'm very glad to hear that it's working!

First, what surveillance rules are not needed for: If you just want to
compare a count with a constant number, like the number of new cases > 0,
then you don't need a surveillance rule. You can just use a regular
validation rule. Or you can use a surveillance rule. If the right side of
the equation is just a constant, then both types of rules will function the
same. It doesn't matter which one you use.

The reason for surveillance rules are to compare a new number against
historical data for the same organisation unit. For example let's say that
the usual, expected number of dysentery cases is some low number that
varies according to site, district,etc. You may want to know when the
number at a clinic increases by more than, say, 25% over the usual number.
You may also want to know when the number of dysentery cases in a whole
district increases by more than, say, 8% over the usual number. You can
define two surveillance rules for this:

Rule 1:
Organisation unit level: (site level)
Left side: number of new dysentery cases.
Operator: <=
Right side: number of new dysentery cases * 1.25.

Rule 2:
Organisation unit level: (district level)
Left side: number of new dysentery cases.
Operator: <=
Right side: number of new dysentery cases * 1.08.

Note that the same data element "number of new dysentery cases" is
evaluated for the period of interest when it is on the left side, and for
previous periods when it is on the right side.

The other surveillance parameters can be used to further configure how the
previous "usual" number of dysentery cases is computed. Let's say a typical
monthly number at a clinic is 3. But if the month before was 1 and the
current month is 2, this is a 100% increase and so could trigger an alert.
So instead you may want to average the previous 4 months and compare
against that average. So set the sequential sample count to 4.

Many "normal" levels have a seasonal variation, so you may want to compare
against data from the same time of the year in previous years. So set the
annual sample count to the number of years you want to go back.

Finally, you may want to throw out some of the highest and/or lowest
previous numbers before averaging. You may want to throw out the highest
count(s) because you don't want previous outbreaks to mask the fact that
you're having another one now. You may want to throw out the lowest
count(s) because you don't want an abnormally low previous period value to
cause undue alarm if this period just returns to normal (such as in the the
example above of a period with only 1 dysentery case, returning to 2.)

When using a surveillance rule, the sequential sample count and/or the
annual sample count should be at least 1. In the future, the surveillance
rule form should check to make sure you do before saving, but we don't have
this logic working yet.

I hope this helps.

Cheers,
Jim



On Fri, Nov 29, 2013 at 10:18 AM, Lars Helge Øverland
<larshelge@xxxxxxxxx>wrote:

> Okay thanks. Let us know if you have any questions of if something
> particular is confusing.
>
>
> On Fri, Nov 29, 2013 at 4:11 PM, Jason Pickering <
> jason.p.pickering@xxxxxxxxx> wrote:
>
>> Hi Lars,
>> I have not managed to figure out /implement the surveillance rules yet,
>> but the normal validation rules seem to be working as expected now. Thanks.
>>
>> Best regards,
>> Jason
>>
>>
>>
>> On Fri, Nov 29, 2013 at 5:09 PM, Lars Helge Øverland <larshelge@xxxxxxxxx
>> > wrote:
>>
>>> Hi Jason,
>>>
>>> for the record, we did a bug-fix related to validation rules some time
>>> ago, is this now okay?
>>>
>>> Lars
>>>
>>>
>>
>