dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Hi Ola,

Actually the alert does not keep going off. Each time the nightly
surveillance run starts, it records in a system property the time of the
start. In the subsequent run the next night, it only considers alerts that
involve data values that have been entered since the start of the pervious
run.

We save the start of the run to be conservative, just in case new data is
entered in the middle of a run as the alert task is running. Worst case is
if some data is entered in the middle of a run, it may be reported that
night and the next night too -- which is better than not reporting it at
all.

The time is noted at the start of the run, but not written in the database
until the end of the run. So if there is a system failure in the middle of
the alert run, the new data will be reported in the next run.

The very first time the alerts are run, it looks at all the data from the
periods just finished (previous day, previous week, previous month, etc.)
After that, subsequent runs just give the "new" incremental news.

So the alerts are kind of like a "headline news" service, to report the
latest news. This can be used for data quality (in which case the data
should be fixed so the alerts are "resolved") or for surveillance, in which
case the data should not necessarily be "resolved" because it is reporting
a health issue of concern. You can configure different rules going to
different groups of users for one or both types of these functions on the
same system.

In the case of data quality, a user can always run the same validations
again at any point (covering as much past data as they like) to see if any
issues have been resolved.

Cheers,
Jim



On Thu, Mar 13, 2014 at 4:05 PM, Ola Hodne Titlestad <olati@xxxxxxxxxx>wrote:

> Hi,
>
> I also see a need to be able to configure how we deal with (repeated)
> alerts over time.
> If the data is not changed the alert will be re-created every night as it
> is right now, correct?
>
> I have some ideas for improvements, but would be good to hear what others
> are thinking here.
>
> - should we have some kind of status on the alert, to turn it off or
> "snooze (1 day, 3 days, 7 days etc.)" that the alert recipients can update?
> - should we allow the pre-configuration of how alerts are repeated? -e.g.
> send again after 1,3,5,7,10 days if data has not changed.
> - should we allow for pre-configuration of escalating alerts where new
> user groups are alerted if the alert is not "resolved"? E.g. (just an
> example):
> <1st> (0 days) alert to <district surveillance officers>, <2nd> alert
> after <7> days to <province surveillance officers>, <3rd> alert after <12
> days> to <national surveillance officers>
>
> Ola
> -----
>
>
>
> ----------------------------------
> Ola Hodne Titlestad (Mr)
> HISP
> Department of Informatics
> University of Oslo
>
> Mobile: +47 48069736
> Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link<https://maps.google.com/maps?q=Eftas%C3%A5sen+68,+0687+Oslo,+Norge&hl=en&ie=UTF8&sll=59.893855,10.785116&sspn=0.222842,0.585709&oq=eftas%C3%A5sen+68,+0687+Oslo,+&t=h&hnear=Eftas%C3%A5sen+68,+%C3%98stensj%C3%B8,+0687+Oslo,+Norway&z=16>
>
>
> On 13 March 2014 09:13, Prosper BT <ptb3000@xxxxxxxxx> wrote:
>
>> Thanks Guys,
>>
>> I think the role was also affecting its use, I go for user groups.
>>
>> Regards
>>
>>
>> On Thu, Mar 13, 2014 at 11:12 AM, Lars Helge Øverland <
>> larshelge@xxxxxxxxx> wrote:
>>
>>> Good. I would say lets change to groups, not too many are using it still.
>>>
>>> Lars
>>> On Mar 12, 2014 6:44 PM, "Jim Grace" <jimgrace@xxxxxxxxx> wrote:
>>>
>>>> An option to configure this per validation rule group sounds fine. In
>>>> the interest of not making this too complicated for the user, would it
>>>> better to leave it with roles (optionally restricted within the org unit
>>>> hierarchy), or change the implementation from roles to user groups
>>>> (optionally restricted within the org unit hierarchy).
>>>>
>>>> Of course we could support both roles and user groups, but I'm just
>>>> trying to see if we can keep it simpler for the user.
>>>>
>>>> Cheers,
>>>> Jim
>>>>
>>>>
>>>>
>>>> On Wed, Mar 12, 2014 at 1:11 PM, Lars Helge Øverland <
>>>> larshelge@xxxxxxxxx> wrote:
>>>>
>>>>> I think the suggestion from Jim is good. Could it be configurable by
>>>>> validation rule group? So we have a true/false option "send alerts to users
>>>>> within hierarchy only" or similar on the validation rule group. Then
>>>>> messages only goes out to users who have the originating org unit of the
>>>>> alert in their sub-hierarchies.
>>>>>
>>>>> I think in general having user roles and not user groups was a (my)
>>>>> mistake - we could simply change it.
>>>>>
>>>>> regards,
>>>>>
>>>>> Lars
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 6, 2014 at 8:26 PM, Prosper BT <ptb3000@xxxxxxxxx> wrote:
>>>>>
>>>>>> Yes Jim this would suit my use case, but not sure if its global
>>>>>> enough others can comment may be
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 6, 2014 at 10:23 PM, Jim Grace <jimgrace@xxxxxxxxx>wrote:
>>>>>>
>>>>>>> Maybe the most useful next step is to leave the user interface the
>>>>>>> same, but filter for the organisation unit assigned to the user when
>>>>>>> sending the messages. So for example a national user would see alerts from
>>>>>>> anywhere in the country, but a district user would see alerts only from
>>>>>>> within their district. (We probably should have done it that way in the
>>>>>>> first place!) Would this help?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jim
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 6, 2014 at 2:15 PM, Prosper BT <ptb3000@xxxxxxxxx>wrote:
>>>>>>>
>>>>>>>> Thanks Jim for the quick response.
>>>>>>>>
>>>>>>>> As we talk about the two the more I see them complicated.
>>>>>>>>
>>>>>>>> For the user role, my use case is on the Uganda national system
>>>>>>>> where user roles and creating users is guarded like a gold mine. Only two
>>>>>>>> people allowed to create roles and users though the rest of us can create
>>>>>>>> user groups. But for now I will ask them to create a user role with only
>>>>>>>> one role that can do much with the system and try it out.
>>>>>>>>
>>>>>>>> For the second one, my use case is in four districts where
>>>>>>>> community health workers are sending weekly maternal surveillance reports.
>>>>>>>> These are like over 4000 villages in level 5 on the hierarchy. I want
>>>>>>>> districts at level 3 to receive alerts whenever a death is reported
>>>>>>>>
>>>>>>>> So if I implement it the way it is now, I have to create 4 district
>>>>>>>> accounts and assign all them the alert user role. Once a death happen in
>>>>>>>> one district all the districts will receive the alert.
>>>>>>>>
>>>>>>>> May be as you suggest we should add hierarchy selection (level) in
>>>>>>>> creating the rule and if we specify sending to a given level (district,
>>>>>>>>  region, national,...) an alert is only sent to only users assigned to that
>>>>>>>> level and only for that hierarchy of that orgunit.
>>>>>>>>
>>>>>>>> Example
>>>>>>>>
>>>>>>>> Uganda/Northern Region/Gulu District/Alur Soubcounty/Gulu
>>>>>>>> Hospital/Village A
>>>>>>>> Uganda/Western Region/Kibaale District/Mutoke Soubcounty/Kagadi
>>>>>>>> Hospital/Village W
>>>>>>>>
>>>>>>>> If death is reported from Village W and the rule was set to send to
>>>>>>>> only users at level 3 only users assigned to Kibaale District with the
>>>>>>>> alert role should receive the alert, but if level 1 is chosen then all
>>>>>>>> users assigned to Uganda would receive the alert.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 6, 2014 at 9:39 PM, Jim Grace <jimgrace@xxxxxxxxx>wrote:
>>>>>>>>
>>>>>>>>> You also raise a good point about sending alerts from different
>>>>>>>>> parts of the org unit hierarchy to different groups of users. I'm trying to
>>>>>>>>> imagine how this could be configured. Perhaps when you configure a
>>>>>>>>> validation rule group you could choose a point in the org unit hierarchy
>>>>>>>>> and assign a user group to be alerted for organisations at or below that
>>>>>>>>> point -- and then you could make similar assignments for other points in
>>>>>>>>> the org unit hierarchy as well. This sounds very useful to me, if a bit
>>>>>>>>> awkward. Can you imagine a simpler mechanism?
>>>>>>>>>
>>>>>>>>> If you can say a bit more about the use case, that also
>>>>>>>>> strengthens the case for a new feature. In particular, can you tell me what
>>>>>>>>> kinds of position(s) the users have who want to know about maternal
>>>>>>>>> or neonatal deaths in their district?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 6, 2014 at 1:17 PM, Jim Grace <jimgrace@xxxxxxxxx>wrote:
>>>>>>>>>
>>>>>>>>>> Prosper, thanks for the feedback. The role is only used to
>>>>>>>>>> identify a group of users, so it doesn't matter what authorities the role
>>>>>>>>>> has. You could create any number of otherwise dummy roles for this purpose.
>>>>>>>>>>
>>>>>>>>>> But your point is very well taken that user groups are in general
>>>>>>>>>> easier to set up and administer (without needing the authority to create
>>>>>>>>>> roles.) That's a very good suggestion for the future.
>>>>>>>>>>
>>>>>>>>>>  Thanks,
>>>>>>>>>> Jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 6, 2014 at 12:53 PM, Prosper BT <ptb3000@xxxxxxxxx>wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear Team and Jim
>>>>>>>>>>>
>>>>>>>>>>> Thanks for this validation rule type that helps us send alerts
>>>>>>>>>>> above set thresholds. Am planning to implement it on one of our use case -
>>>>>>>>>>> Maternal and Neonatal Weekly death reports. Basically I want sms sent to a
>>>>>>>>>>> group of users whenever a maternal or neonatal death is reported.
>>>>>>>>>>>
>>>>>>>>>>> First of all the two challenges I have are:
>>>>>>>>>>>
>>>>>>>>>>> - Sending to users assigned a given user role as opposed to
>>>>>>>>>>> sending to users in a given group. Its easier to send to a user group as
>>>>>>>>>>> opposed to the current design that only allows to send to users assigned a
>>>>>>>>>>> given user role. First of all am not sure what different authorities this
>>>>>>>>>>> role should have. Secondary in a situation where I have no rights to create
>>>>>>>>>>> a user role I cant implement this like the case of Uganda national DHIS2.
>>>>>>>>>>>
>>>>>>>>>>> So I would suggest we either add sending to a user group.
>>>>>>>>>>>
>>>>>>>>>>> - Ability to localize the alerts to the hierarchy; right now we
>>>>>>>>>>> can only send alerts to a central team otherwise it creates a lot of noise
>>>>>>>>>>> if we send to user of lower levels for them to be relevant. A user in
>>>>>>>>>>> districts B may not be interested in alerts from district C would rather
>>>>>>>>>>> only receive from his only district. But currently if a user in District B
>>>>>>>>>>> is assigned the alert role, he/she will receive alerts from all districts.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Prosper Behumbiize, MPH
>>>>>>>>>>> Phone:        +256 414 320076
>>>>>>>>>>> Cell:             +256 772 139037
>>>>>>>>>>>                      +256 752 751776
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Prosper Behumbiize, MPH
>>>>>>>> Phone:        +256 414 320076
>>>>>>>> Cell:             +256 772 139037
>>>>>>>>                      +256 752 751776
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Prosper Behumbiize, MPH
>>>>>> Phone:        +256 414 320076
>>>>>> Cell:             +256 772 139037
>>>>>>                      +256 752 751776
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>> --
>> Prosper Behumbiize, MPH
>> Phone:        +256 414 320076
>> Cell:             +256 772 139037
>>                      +256 752 751776
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>