Maps of outbreaks

Dear DHIS2 community, looking for good ideas for a use case which is a bit unusual.

We’d like to map epidemic outbreaks, and the data are very simple: Outbreak or not, in other words, Yes/No per orgunit (a province or district). Perhaps Yes Only would be best here?

The tricky part is the time dimension: We need to produdce maps of affected districts at regular intervals, at least monthly, possibly also more frequent.

However, there is a lot of diversity in the data: Sometimes we have a start and end date, sometimes just a number of months.

Currently, DHIS2 does not support one screen for multiple periods

I see two possibilities:

  1. Create just one dataelement “Outbreak” as Yes Only in a monthly dataset. Then one would have to select every affected month and say YES

  2. Create two additional data elements: “Start date” and “End date” in a YEARLY dataset. Then also write a script behind the scenes which populates the Outbreak dataelement for the affected months - or even extend it to days

Better ideas?

···


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

Hi Knut,
Not exactly sure if this the same, but in one instance which I help to support, we are just concerned about the “latest” data. Data may be submitted for a few months, and maybe stops at a certain point in time when there is no longer a need for regular surveillance. However, when we generate a report for say Feb 2014, we need all the latest data. I think this is somehwat similar to the “On change” period type of DHIS 1.4, but which is not implemented in DHIS2. It might be that you could simply report the latest data (Outbreak = Yes/No) for the month in which the change occurs, and then not bother reporting for the other months.

We have to pull the data out of the system, and create a time series of it, using the “last observation carried forward” approach of time-series analysis to determine what the status of all orgunits is at a given point in time.

Having this type of period/aggregation would also solve some of the problems with certain data elements like “ART current count”, which should never be aggregated in time, but should always simply use the latest value reported.

Best regards,
Jason

···

On Sat, Feb 15, 2014 at 9:16 AM, Knut Staring knutst@gmail.com wrote:

Dear DHIS2 community, looking for good ideas for a use case which is a bit unusual.

We’d like to map epidemic outbreaks, and the data are very simple: Outbreak or not, in other words, Yes/No per orgunit (a province or district). Perhaps Yes Only would be best here?

The tricky part is the time dimension: We need to produdce maps of affected districts at regular intervals, at least monthly, possibly also more frequent.

However, there is a lot of diversity in the data: Sometimes we have a start and end date, sometimes just a number of months.

Currently, DHIS2 does not support one screen for multiple periods

I see two possibilities:

  1. Create just one dataelement “Outbreak” as Yes Only in a monthly dataset. Then one would have to select every affected month and say YES
  1. Create two additional data elements: “Start date” and “End date” in a YEARLY dataset. Then also write a script behind the scenes which populates the Outbreak dataelement for the affected months - or even extend it to days

Better ideas?

Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org


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

Hi Knut,

My two cents as we recently experienced a measles 'outbreak'.

First, better not to call it an 'outbreak'. Health officials are very sensitive about the term. We can gain their confidence if we don't "presume" an outbreak by labeling it as such on the interface.

Second, we missed this 'outbreak' in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We'll leave it up to the health officials to call it an outbreak.

Alvin

···

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring <knutst@gmail.com>
Sender: "Dhis2-users"
<dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net>Date: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.net<dhis2-users@lists.launchpad.net>
Subject: [Dhis2-users] Maps of outbreaks

_______________________________________________
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

I'm not sure if I got the 3Cs correctly. Pls google too...

···

Sent from my BB Curve 9320

-----Original Message-----
From: "Alvin B. Marcelo" <alvin.marcelo@gmail.com>
Date: Sat, 15 Feb 2014 07:41:03
To: Knut Staring<knutst@gmail.com>; Dhis2-users<dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net>; dhis2-users@lists.launchpad.net<dhis2-users@lists.launchpad.net>
Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles 'outbreak'.

First, better not to call it an 'outbreak'. Health officials are very sensitive about the term. We can gain their confidence if we don't "presume" an outbreak by labeling it as such on the interface.

Second, we missed this 'outbreak' in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We'll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring <knutst@gmail.com>
Sender: "Dhis2-users"
<dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net>Date: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.net<dhis2-users@lists.launchpad.net>
Subject: [Dhis2-users] Maps of outbreaks

_______________________________________________
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

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

···

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03
To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com
Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
Subject: [Dhis2-users] Maps of outbreaks


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


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

Thanks a lot, Jason and Alvin for sharing your insights.

I think I might just go with “Report” or “Reported cases” for now. But what remains as a challenge is to easily populate the DHIS2 data value table to allow for the generation of maps. From Jason’s experience, a script may be the way to go. That could be external, or done in javascript inside an app, which could also offer multi-period data entry. However, it would be nice if multi-period data entry could be included in an upcoming release.

···

Knut

On Sat, Feb 15, 2014 at 8:41 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----

From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”

dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23

To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

···

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03
To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com
Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net
Subject: [Dhis2-users] Maps of outbreaks


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


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

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app? It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

Cheers,

Jim

···

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

Hi Alvin

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app? It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

Cheers,

Jim

···

On Saturday, 15 February 2014 7:19 PM, Jim Grace jimgrace@gmail.com wrote:

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…
Yes, i too agree with ‘Inception’, surprisingly its not that much amusing as ‘Dimension’.

:slight_smile:

BRajesh

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think
“Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles
‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack
of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

Thanks for the thoughts, Jim. Some comments below.

···

On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Quite right, I was already wondering how to handle things that cross years. I guess the user should select start and end dates, but these would not be stored. Tending towards preserving the information as much as possible through using a daily dataset - this implies lots of (generated) datavalues for a long outbreak, but is usually for a limited number of orgunits (the total number is over 3000). Monthly data will be interpreted to cover all days in the month.

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

In this particular case there is but one data element and no disaggregations, so it could go either way. It really depends on how you get your data - sometimes you have lots of data for just one OrgUnit, and then it’s a hassle to constantly select new periods when the screen could easily accommodate a matrix grid rather than a one dimensional column.

But of course you would have to somehow specify the number of periods, preferably on a dataset basis rather than as a global setting. We already support the choice of horizontal or vertical (row/column) multi-orgunit data entry, so would not be too far fetched to do something similar for periods (though they are potentially infinite in number). In fact, the OpenHealth prototype that was developed for WHO back in 2007 had a data entry interface quite akin to our Pivot Table.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app?

I would argue that though our Data Entry is already quite powerful, there are a lot of enhancements that I would really love to see in the core. It would be wonderful if most use cases could generate the forms they want without having to do either a custom form or an app, though always seeking to avoid complexity both for the programmers and end-users. I think there are quite a few general form patterns we still don’t support very well.

It would be great to be able to “pivot” the autogenerated data entry forms according to the use case (i.e. the nature of the data). There are also a couple of other things that naturally belong in the core, such as the ability to click or hover on a Data Element in order to see the full definition. I would also like to have out-of-the box Accordion functionality for sections, preferably with arrows to simulate a workflow, so that one would see only one section at a time. We almost have this already, but the dropdown section selector is not as user friendly as either a collapsable accordion (better) or Previous + Next buttons, such as in this (admittedly ugly) example: http://jquery.bassistance.de/validate/demo/multipart/

It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

That is of course a big debate which can perhaps only be fully resolved as we gain experience, but I would mainly argue for strengthening the proud DHIS tradition of providing tools for people who are not programmers allowing them to configure what they want. Both custom forms and Apps are currently quite hard to do - I’d love to see a few more generic options in the main Data Entry, and perhaps also some building blocks to quickly get started with apps beyond the raw API.

Perhaps we need to move that debate to a separate thread, especially in preparation for a new generation student contributors.

Knut

Cheers,

Jim


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

Hi Knut,

Nice thoughts about more flexible data entry forms “pivoting” in different dimensions. And given how much easier the auto-generated forms are than designing your own, it would be great to expand the number of cases that one can use auto-generated forms for. Developing a detailed proposal for this sounds like a very useful effort. Any takers?

I quite agree that we should provide “tools for people who are not programmers allowing them to configure what they want”. My question about the appropriate use of apps isn’t really focused on when do we expect users to write their own. It’s more the question of when are features provided in the core vs. when are they provided in the app store.

Speaking of which, if we provide general-purpose, configurable apps in the app store, I wonder how we can provide a user-friendly way to customize app metadata through DHIS, so the user wouldn’t have to edit the manifest file inside the app. We could extend the DHIS UI to be able to configure app-specific metadata settings for an app that has been uploaded. I wonder if the app manifest itself could describe the various system settings choices to be made (e.g., the allowable numeric range of a metadata setting, the list of choices, etc.) I’m not familiar enough yet with the app manifest format to know whether it supports this already, or how awkward it might be to graft it on. I known that OpenMRS modules, for example, can add their own settings section to the OpenMRS UI, so they can be configured through OpenMRS. The end result is that the non-programmer user can simply download an OpenMRS module, install it, and then configure it through the OpenMRS UI. The equivalent for DHIS apps could be very useful. Or should the app include its own configuration screens, and the configuration data is somehow stored in DHIS? (I apologize for my lack of knowledge about apps.)

···

Cheers,

Jim

On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring knutst@gmail.com wrote:

Thanks for the thoughts, Jim. Some comments below.

On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Quite right, I was already wondering how to handle things that cross years. I guess the user should select start and end dates, but these would not be stored. Tending towards preserving the information as much as possible through using a daily dataset - this implies lots of (generated) datavalues for a long outbreak, but is usually for a limited number of orgunits (the total number is over 3000). Monthly data will be interpreted to cover all days in the month.

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

In this particular case there is but one data element and no disaggregations, so it could go either way. It really depends on how you get your data - sometimes you have lots of data for just one OrgUnit, and then it’s a hassle to constantly select new periods when the screen could easily accommodate a matrix grid rather than a one dimensional column.

But of course you would have to somehow specify the number of periods, preferably on a dataset basis rather than as a global setting. We already support the choice of horizontal or vertical (row/column) multi-orgunit data entry, so would not be too far fetched to do something similar for periods (though they are potentially infinite in number). In fact, the OpenHealth prototype that was developed for WHO back in 2007 had a data entry interface quite akin to our Pivot Table.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app?

I would argue that though our Data Entry is already quite powerful, there are a lot of enhancements that I would really love to see in the core. It would be wonderful if most use cases could generate the forms they want without having to do either a custom form or an app, though always seeking to avoid complexity both for the programmers and end-users. I think there are quite a few general form patterns we still don’t support very well.

It would be great to be able to “pivot” the autogenerated data entry forms according to the use case (i.e. the nature of the data). There are also a couple of other things that naturally belong in the core, such as the ability to click or hover on a Data Element in order to see the full definition. I would also like to have out-of-the box Accordion functionality for sections, preferably with arrows to simulate a workflow, so that one would see only one section at a time. We almost have this already, but the dropdown section selector is not as user friendly as either a collapsable accordion (better) or Previous + Next buttons, such as in this (admittedly ugly) example: http://jquery.bassistance.de/validate/demo/multipart/

It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

That is of course a big debate which can perhaps only be fully resolved as we gain experience, but I would mainly argue for strengthening the proud DHIS tradition of providing tools for people who are not programmers allowing them to configure what they want. Both custom forms and Apps are currently quite hard to do - I’d love to see a few more generic options in the main Data Entry, and perhaps also some building blocks to quickly get started with apps beyond the raw API.

Perhaps we need to move that debate to a separate thread, especially in preparation for a new generation student contributors.

Knut

Cheers,

Jim


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

Hi Knut

At the risk of appearing even more ignorant, doesn’t this scenario bear some resemblance to tracked-entity-event, particularly as we have moved to generalize this beyond the scope of tracked persons? Soi event 1, some time in September, is a measles “outbreak” in a district. Event 2, some months later, signals the end of the “outbreak” in that district.

Looking at tracker logic and seeing an outbreak-inception-incursion as something similar to a stage-in-a-program is perhaps an odd thought but it could be that the model works it is just the words which are wrong.

Maybe thats an off the wall thought, but couldn’t help sharing … :slight_smile:

Bob

···

On 15 February 2014 07:16, Knut Staring knutst@gmail.com wrote:

Dear DHIS2 community, looking for good ideas for a use case which is a bit unusual.

We’d like to map epidemic outbreaks, and the data are very simple: Outbreak or not, in other words, Yes/No per orgunit (a province or district). Perhaps Yes Only would be best here?

The tricky part is the time dimension: We need to produdce maps of affected districts at regular intervals, at least monthly, possibly also more frequent.

However, there is a lot of diversity in the data: Sometimes we have a start and end date, sometimes just a number of months.

Currently, DHIS2 does not support one screen for multiple periods

I see two possibilities:

  1. Create just one dataelement “Outbreak” as Yes Only in a monthly dataset. Then one would have to select every affected month and say YES
  1. Create two additional data elements: “Start date” and “End date” in a YEARLY dataset. Then also write a script behind the scenes which populates the Outbreak dataelement for the affected months - or even extend it to days

Better ideas?

Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org


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

Thanks Jim - I will try to find time to get more Data Entry ideas into a Blueprint.

Also very much like your thoughts about extending the current bare-bones app management in DHIS2 to include configuration of each app - maybe something for GSoC?

Knut

···

On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

Nice thoughts about more flexible data entry forms “pivoting” in different dimensions. And given how much easier the auto-generated forms are than designing your own, it would be great to expand the number of cases that one can use auto-generated forms for. Developing a detailed proposal for this sounds like a very useful effort. Any takers?

I quite agree that we should provide “tools for people who are not programmers allowing them to configure what they want”. My question about the appropriate use of apps isn’t really focused on when do we expect users to write their own. It’s more the question of when are features provided in the core vs. when are they provided in the app store.

Speaking of which, if we provide general-purpose, configurable apps in the app store, I wonder how we can provide a user-friendly way to customize app metadata through DHIS, so the user wouldn’t have to edit the manifest file inside the app. We could extend the DHIS UI to be able to configure app-specific metadata settings for an app that has been uploaded. I wonder if the app manifest itself could describe the various system settings choices to be made (e.g., the allowable numeric range of a metadata setting, the list of choices, etc.) I’m not familiar enough yet with the app manifest format to know whether it supports this already, or how awkward it might be to graft it on. I known that OpenMRS modules, for example, can add their own settings section to the OpenMRS UI, so they can be configured through OpenMRS. The end result is that the non-programmer user can simply download an OpenMRS module, install it, and then configure it through the OpenMRS UI. The equivalent for DHIS apps could be very useful. Or should the app include its own configuration screens, and the configuration data is somehow stored in DHIS? (I apologize for my lack of knowledge about apps.)


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

Cheers,

Jim

On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring knutst@gmail.com wrote:

Thanks for the thoughts, Jim. Some comments below.

On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Quite right, I was already wondering how to handle things that cross years. I guess the user should select start and end dates, but these would not be stored. Tending towards preserving the information as much as possible through using a daily dataset - this implies lots of (generated) datavalues for a long outbreak, but is usually for a limited number of orgunits (the total number is over 3000). Monthly data will be interpreted to cover all days in the month.

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

In this particular case there is but one data element and no disaggregations, so it could go either way. It really depends on how you get your data - sometimes you have lots of data for just one OrgUnit, and then it’s a hassle to constantly select new periods when the screen could easily accommodate a matrix grid rather than a one dimensional column.

But of course you would have to somehow specify the number of periods, preferably on a dataset basis rather than as a global setting. We already support the choice of horizontal or vertical (row/column) multi-orgunit data entry, so would not be too far fetched to do something similar for periods (though they are potentially infinite in number). In fact, the OpenHealth prototype that was developed for WHO back in 2007 had a data entry interface quite akin to our Pivot Table.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app?

I would argue that though our Data Entry is already quite powerful, there are a lot of enhancements that I would really love to see in the core. It would be wonderful if most use cases could generate the forms they want without having to do either a custom form or an app, though always seeking to avoid complexity both for the programmers and end-users. I think there are quite a few general form patterns we still don’t support very well.

It would be great to be able to “pivot” the autogenerated data entry forms according to the use case (i.e. the nature of the data). There are also a couple of other things that naturally belong in the core, such as the ability to click or hover on a Data Element in order to see the full definition. I would also like to have out-of-the box Accordion functionality for sections, preferably with arrows to simulate a workflow, so that one would see only one section at a time. We almost have this already, but the dropdown section selector is not as user friendly as either a collapsable accordion (better) or Previous + Next buttons, such as in this (admittedly ugly) example: http://jquery.bassistance.de/validate/demo/multipart/

It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

That is of course a big debate which can perhaps only be fully resolved as we gain experience, but I would mainly argue for strengthening the proud DHIS tradition of providing tools for people who are not programmers allowing them to configure what they want. Both custom forms and Apps are currently quite hard to do - I’d love to see a few more generic options in the main Data Entry, and perhaps also some building blocks to quickly get started with apps beyond the raw API.

Perhaps we need to move that debate to a separate thread, especially in preparation for a new generation student contributors.

Knut

Cheers,

Jim


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

One could indeed make an app for appsetting management since devs can already save/retrieve settings for apps by using the usersettings or systemsettings web api.

Knut, I think its quite feasible for this app to be built during gsoc 3-month timeline.

This app can also help create convention on how apps should name their settings.
Something like settings.. can be managed through the app’s UI

···

Regards,
Saptarshi PURKAYASTHA

On 16 February 2014 00:23, Knut Staring knutst@gmail.com wrote:

Thanks Jim - I will try to find time to get more Data Entry ideas into a Blueprint.

Also very much like your thoughts about extending the current bare-bones app management in DHIS2 to include configuration of each app - maybe something for GSoC?

Knut


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

On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

Nice thoughts about more flexible data entry forms “pivoting” in different dimensions. And given how much easier the auto-generated forms are than designing your own, it would be great to expand the number of cases that one can use auto-generated forms for. Developing a detailed proposal for this sounds like a very useful effort. Any takers?

I quite agree that we should provide “tools for people who are not programmers allowing them to configure what they want”. My question about the appropriate use of apps isn’t really focused on when do we expect users to write their own. It’s more the question of when are features provided in the core vs. when are they provided in the app store.

Speaking of which, if we provide general-purpose, configurable apps in the app store, I wonder how we can provide a user-friendly way to customize app metadata through DHIS, so the user wouldn’t have to edit the manifest file inside the app. We could extend the DHIS UI to be able to configure app-specific metadata settings for an app that has been uploaded. I wonder if the app manifest itself could describe the various system settings choices to be made (e.g., the allowable numeric range of a metadata setting, the list of choices, etc.) I’m not familiar enough yet with the app manifest format to know whether it supports this already, or how awkward it might be to graft it on. I known that OpenMRS modules, for example, can add their own settings section to the OpenMRS UI, so they can be configured through OpenMRS. The end result is that the non-programmer user can simply download an OpenMRS module, install it, and then configure it through the OpenMRS UI. The equivalent for DHIS apps could be very useful. Or should the app include its own configuration screens, and the configuration data is somehow stored in DHIS? (I apologize for my lack of knowledge about apps.)


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

Cheers,

Jim

On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring knutst@gmail.com wrote:

Thanks for the thoughts, Jim. Some comments below.

On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Quite right, I was already wondering how to handle things that cross years. I guess the user should select start and end dates, but these would not be stored. Tending towards preserving the information as much as possible through using a daily dataset - this implies lots of (generated) datavalues for a long outbreak, but is usually for a limited number of orgunits (the total number is over 3000). Monthly data will be interpreted to cover all days in the month.

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

In this particular case there is but one data element and no disaggregations, so it could go either way. It really depends on how you get your data - sometimes you have lots of data for just one OrgUnit, and then it’s a hassle to constantly select new periods when the screen could easily accommodate a matrix grid rather than a one dimensional column.

But of course you would have to somehow specify the number of periods, preferably on a dataset basis rather than as a global setting. We already support the choice of horizontal or vertical (row/column) multi-orgunit data entry, so would not be too far fetched to do something similar for periods (though they are potentially infinite in number). In fact, the OpenHealth prototype that was developed for WHO back in 2007 had a data entry interface quite akin to our Pivot Table.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app?

I would argue that though our Data Entry is already quite powerful, there are a lot of enhancements that I would really love to see in the core. It would be wonderful if most use cases could generate the forms they want without having to do either a custom form or an app, though always seeking to avoid complexity both for the programmers and end-users. I think there are quite a few general form patterns we still don’t support very well.

It would be great to be able to “pivot” the autogenerated data entry forms according to the use case (i.e. the nature of the data). There are also a couple of other things that naturally belong in the core, such as the ability to click or hover on a Data Element in order to see the full definition. I would also like to have out-of-the box Accordion functionality for sections, preferably with arrows to simulate a workflow, so that one would see only one section at a time. We almost have this already, but the dropdown section selector is not as user friendly as either a collapsable accordion (better) or Previous + Next buttons, such as in this (admittedly ugly) example: http://jquery.bassistance.de/validate/demo/multipart/

It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

That is of course a big debate which can perhaps only be fully resolved as we gain experience, but I would mainly argue for strengthening the proud DHIS tradition of providing tools for people who are not programmers allowing them to configure what they want. Both custom forms and Apps are currently quite hard to do - I’d love to see a few more generic options in the main Data Entry, and perhaps also some building blocks to quickly get started with apps beyond the raw API.

Perhaps we need to move that debate to a separate thread, especially in preparation for a new generation student contributors.

Knut

Cheers,

Jim


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

A slight detour of the thread, but how about a server side apps part for gsoc. So we can process the web api on the server on behalf of the client. For non javascript enabled clients such as SMS and mobile light? Server side javascript or other…

And a json db for apps would be nice. Instead of just settings… That would have been good during the inf5750 group work.

Lars

  1. feb. 2014 20:06 skrev “Saptarshi Purkayastha” sunbiz@gmail.com følgende:
···

Regards,
Saptarshi PURKAYASTHA

On 16 February 2014 00:23, Knut Staring knutst@gmail.com wrote:

Thanks Jim - I will try to find time to get more Data Entry ideas into a Blueprint.

Also very much like your thoughts about extending the current bare-bones app management in DHIS2 to include configuration of each app - maybe something for GSoC?

Knut


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

On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

Nice thoughts about more flexible data entry forms “pivoting” in different dimensions. And given how much easier the auto-generated forms are than designing your own, it would be great to expand the number of cases that one can use auto-generated forms for. Developing a detailed proposal for this sounds like a very useful effort. Any takers?

I quite agree that we should provide “tools for people who are not programmers allowing them to configure what they want”. My question about the appropriate use of apps isn’t really focused on when do we expect users to write their own. It’s more the question of when are features provided in the core vs. when are they provided in the app store.

Speaking of which, if we provide general-purpose, configurable apps in the app store, I wonder how we can provide a user-friendly way to customize app metadata through DHIS, so the user wouldn’t have to edit the manifest file inside the app. We could extend the DHIS UI to be able to configure app-specific metadata settings for an app that has been uploaded. I wonder if the app manifest itself could describe the various system settings choices to be made (e.g., the allowable numeric range of a metadata setting, the list of choices, etc.) I’m not familiar enough yet with the app manifest format to know whether it supports this already, or how awkward it might be to graft it on. I known that OpenMRS modules, for example, can add their own settings section to the OpenMRS UI, so they can be configured through OpenMRS. The end result is that the non-programmer user can simply download an OpenMRS module, install it, and then configure it through the OpenMRS UI. The equivalent for DHIS apps could be very useful. Or should the app include its own configuration screens, and the configuration data is somehow stored in DHIS? (I apologize for my lack of knowledge about apps.)


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

Cheers,

Jim

On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring knutst@gmail.com wrote:

Thanks for the thoughts, Jim. Some comments below.

On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Knut,

It sounds to me like a natural for an app (as you mentioned). If we had “Start date” and “End date” in a YEARLY dataset, that might preclude two outbreaks (by any other name) for the same year and same organisation unit, so that might not be the best method for data entry. (And outbreaks that span the new year would still have to be entered twice.)

Quite right, I was already wondering how to handle things that cross years. I guess the user should select start and end dates, but these would not be stored. Tending towards preserving the information as much as possible through using a daily dataset - this implies lots of (generated) datavalues for a long outbreak, but is usually for a limited number of orgunits (the total number is over 3000). Monthly data will be interpreted to cover all days in the month.

Interesting idea about entering through time on the same form. I wonder what that would look like. Would the periods be columns? Given that we already use columns for disaggregations, that might make the form too wide – so maybe the periods would be rows. I wonder how the number of periods would be determined – perhaps specify the number in the form design (or in the data set for an automatically-generated form), or maybe specify a longer period type and show all periods within the longer duration.

In this particular case there is but one data element and no disaggregations, so it could go either way. It really depends on how you get your data - sometimes you have lots of data for just one OrgUnit, and then it’s a hassle to constantly select new periods when the screen could easily accommodate a matrix grid rather than a one dimensional column.

But of course you would have to somehow specify the number of periods, preferably on a dataset basis rather than as a global setting. We already support the choice of horizontal or vertical (row/column) multi-orgunit data entry, so would not be too far fetched to do something similar for periods (though they are potentially infinite in number). In fact, the OpenHealth prototype that was developed for WHO back in 2007 had a data entry interface quite akin to our Pivot Table.

Most of all I wonder what other use cases there might be for entry over multiple time periods. Is this worth building in, or is it best done by an app?

I would argue that though our Data Entry is already quite powerful, there are a lot of enhancements that I would really love to see in the core. It would be wonderful if most use cases could generate the forms they want without having to do either a custom form or an app, though always seeking to avoid complexity both for the programmers and end-users. I think there are quite a few general form patterns we still don’t support very well.

It would be great to be able to “pivot” the autogenerated data entry forms according to the use case (i.e. the nature of the data). There are also a couple of other things that naturally belong in the core, such as the ability to click or hover on a Data Element in order to see the full definition. I would also like to have out-of-the box Accordion functionality for sections, preferably with arrows to simulate a workflow, so that one would see only one section at a time. We almost have this already, but the dropdown section selector is not as user friendly as either a collapsable accordion (better) or Previous + Next buttons, such as in this (admittedly ugly) example: http://jquery.bassistance.de/validate/demo/multipart/

It seems like a good idea to develop apps for a lot of specialized requirements, and maybe even some common ones. How much have we developed our philosophy about when to put things in apps and when in the core product?

That is of course a big debate which can perhaps only be fully resolved as we gain experience, but I would mainly argue for strengthening the proud DHIS tradition of providing tools for people who are not programmers allowing them to configure what they want. Both custom forms and Apps are currently quite hard to do - I’d love to see a few more generic options in the main Data Entry, and perhaps also some building blocks to quickly get started with apps beyond the raw API.

Perhaps we need to move that debate to a separate thread, especially in preparation for a new generation student contributors.

Knut

Cheers,

Jim


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org

On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

+1 on Inception (in the context of the movie)…It may seem amusing but to some extent the term is appropriate…

Sent from my BB Curve 9320


From: Brajesh Murari brajesh.murari@yahoo.com

Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT)

To: alvin.marcelo@gmail.comalvin.marcelo@gmail.com; Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

ReplyTo: Brajesh Murari brajesh.murari@yahoo.com

Subject: Re: [Dhis2-users] Maps of outbreaks

Hi,

There are some synonyms for ‘outbreak’ are given below

explosion, blast, eruption, outburst, detonation, blowup, outburst, plosion, advent, repullulation, commence, inception, initiation, inchoation, eruption, insurgency,

I think “Insurgency” or ‘Inception’ would be nice to use for ‘outbreak’ in context of DHIS2.

Regards

Brajesh Murari

On Saturday, 15 February 2014 1:25 PM, Alvin B. Marcelo alvin.marcelo@gmail.com wrote:

I’m not sure if I got the 3Cs correctly. Pls google too…

Sent from my BB Curve 9320

-----Original Message-----
From: “Alvin B. Marcelo” alvin.marcelo@gmail.com
Date: Sat, 15 Feb 2014 07:41:03

To: Knut Staringknutst@gmail.com; Dhis2-usersdhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.net; dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Reply-To: alvin.marcelo@gmail.com
Subject: Re: [Dhis2-users] Maps of outbreaks

Hi Knut,

My two cents as we recently experienced a measles ‘outbreak’.

First, better not to call it an ‘outbreak’. Health officials are very sensitive about the term. We can gain their confidence if we don’t “presume” an outbreak by labeling it as such on the interface.

Second, we missed this ‘outbreak’ in Metro Manila (of all places!) because the health workers waited for official lab confirmation (which takes 3 weeks in this part of the world). The health workers forgot to execute the protocol that if the 3Cs are present (colds, cohryza, conjunctivitis) they should suspect measles and immediately vaccinate the surrounding children.

Lesson: if any child comes in with any one of the 3Cs, the information system should alert them for the other 2Cs. The 3Cs will be reported upwards and it will be a syndromic report and not an outbreak report.

The first syndromes (in retrospect) started coming in as early as August but it was only December when the trend became evident (due to the lack of near-real time reporting and health worker forgetting the protocol).

I fully support this initiative. Such a system, if it works, could have saved lives in the Philippines. A better name might be DHIS2 syndromic surveillance decision support system with the ability to inform officials of dangerous trends.

We’ll leave it up to the health officials to call it an outbreak.

Alvin

Sent from my BB Curve 9320

-----Original Message-----
From: Knut Staring knutst@gmail.com

Sender: “Dhis2-users”
dhis2-users-bounces+alvin.marcelo=gmail.com@lists.launchpad.netDate: Sat, 15 Feb 2014 08:16:23
To: dhis2-users@lists.launchpad.netdhis2-users@lists.launchpad.net

Subject: [Dhis2-users] Maps of outbreaks


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


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


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

Hi Bob,

Will not get into the semantics here. :expressionless:

Without really knowing any details of the data , beyond what Knut has shared with us, but it certainly seems more like “Event” data than the sort of routine data which the current data entry UI is geared to. Our use case is somewhat more in the middle, meaning that we conduct surveillance for a certain period of time, and then stop. So, we might have data for Jan-June for one Orgunit A and Feb-August for Orgunit B. What we would like to see however when we look at “August” in the Pivots/GIS/etc would be the latest values, i.e. June data for the first orgunit in the example and August data for the second orgunit. It would really not make sense to enter data for July and August for for Orgunit A first because we have none really and if we did, it would be repetitive.

Knut in your case, it would seem to make little sense to enter data for months for which it does not exist, just to be able to visualize it. However, as is often the case with event type of data, what matters in some analyses is the data which was last observed. I think this is the difference between what you are proposing and how we handle it here. What we need is an aggregation method for the time dimension which retrieves the latest data only for a given orgunit/datalement/categorycombo.

I certainly see the need for being able to enter data for a single orgunit for multiple periods though. Some data, like population figures, need to be entered over many time periods, and from a workflow perspective, would simplify things a bit.

Regards,

Jason

···

On Sat, Feb 15, 2014 at 7:13 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Knut

At the risk of appearing even more ignorant, doesn’t this scenario bear some resemblance to tracked-entity-event, particularly as we have moved to generalize this beyond the scope of tracked persons? Soi event 1, some time in September, is a measles “outbreak” in a district. Event 2, some months later, signals the end of the “outbreak” in that district.

Looking at tracker logic and seeing an outbreak-inception-incursion as something similar to a stage-in-a-program is perhaps an odd thought but it could be that the model works it is just the words which are wrong.

Maybe thats an off the wall thought, but couldn’t help sharing … :slight_smile:

Bob


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

On 15 February 2014 07:16, Knut Staring knutst@gmail.com wrote:

Dear DHIS2 community, looking for good ideas for a use case which is a bit unusual.

We’d like to map epidemic outbreaks, and the data are very simple: Outbreak or not, in other words, Yes/No per orgunit (a province or district). Perhaps Yes Only would be best here?

The tricky part is the time dimension: We need to produdce maps of affected districts at regular intervals, at least monthly, possibly also more frequent.

However, there is a lot of diversity in the data: Sometimes we have a start and end date, sometimes just a number of months.

Currently, DHIS2 does not support one screen for multiple periods

I see two possibilities:

  1. Create just one dataelement “Outbreak” as Yes Only in a monthly dataset. Then one would have to select every affected month and say YES
  1. Create two additional data elements: “Start date” and “End date” in a YEARLY dataset. Then also write a script behind the scenes which populates the Outbreak dataelement for the affected months - or even extend it to days

Better ideas?

Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org


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

Thanks good people.

Unless is laboratory confirmed, it is always a “suspected” case of measles or polio or acute flaccid paralysis (AFP). That means that you’ve to have another variable on results.

regards

PEPELA WANJALA

MINISTRY OF HEALTH HEADQUARTERS

HEALTH INFORMATION SYSTEM

AFYA HOUSE, HIS LG 37

** P.O BOX 30016, NAIROBI, KENYA**

TEL: +254 (020) 2717077 EXT 45097

CELL: +254 (0) 722375633 or 0202033363

EMAIL: wanjala2p@yahoo.com

** hmis@health.go.ke**

* *"HealthInformation Management - Making a World of Difference”

Hi Bob,

Will not get into the semantics here. :expressionless:

Without really knowing any details of the data , beyond what Knut has shared with us, but it certainly seems more like “Event” data than the sort of routine data which the current data entry UI is geared to. Our use case is somewhat more in the middle, meaning that we conduct surveillance for a certain period of time, and then stop. So, we might have data for Jan-June for one Orgunit A and Feb-August for Orgunit B. What we would like to see however when we look at “August” in the Pivots/GIS/etc would be the latest values, i.e. June data for the first orgunit in the example and August data for the second orgunit. It would really not make sense to enter data for July and August for for Orgunit A first because we have none really and if we did, it would be repetitive.

Knut in your case, it would seem to make little sense to enter data for months for which it does not exist, just to be able to visualize it. However, as is often the case with event type of data, what matters in some analyses is the data which was last observed. I think this is the difference between what you are proposing and how we handle it here. What we need is an aggregation method for the time dimension which retrieves the latest data only for a given orgunit/datalement/categorycombo.

I certainly see the need for being able to enter data for a single orgunit for multiple periods though. Some data, like population figures, need to be entered over many time periods, and from a workflow perspective, would simplify things a bit.

Regards,

Jason

···

On Sunday, February 16, 2014 9:13 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

On Sat, Feb 15, 2014 at 7:13 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

Hi Knut

At the risk of appearing even more ignorant, doesn’t this scenario bear some resemblance to tracked-entity-event, particularly as we have moved to generalize this beyond the scope of tracked persons? Soi event 1, some time in September, is a measles “outbreak” in a district. Event 2, some months later, signals the end of the “outbreak” in that district.

Looking at tracker logic and seeing an outbreak-inception-incursion as something similar to a stage-in-a-program is perhaps an odd thought but it could be that the model works it is just the words which are wrong.

Maybe thats an off the wall thought, but couldn’t help sharing … :slight_smile:

Bob

On 15 February 2014 07:16, Knut Staring knutst@gmail.com wrote:

Dear DHIS2 community, looking for good ideas for a use case which is a bit unusual.

We’d like to map epidemic outbreaks, and the data are very simple: Outbreak or not, in other words, Yes/No per orgunit (a province or district). Perhaps Yes Only would be best here?

The tricky part is the time dimension: We need to produdce maps of affected districts at regular intervals, at least monthly, possibly also more frequent.

However, there is a lot of diversity in the data: Sometimes we have a start and end date, sometimes just a number of months.

Currently, DHIS2 does not support one screen for multiple periods

I see two possibilities:

  1. Create just one dataelement “Outbreak” as Yes Only in a monthly dataset. Then one would have to select every affected month and say YES
  1. Create two additional data elements: “Start date” and “End date” in a YEARLY dataset. Then also write a script behind the scenes which populates the Outbreak dataelement for the affected months - or even extend it to days

Better ideas?


Knut Staring

Dept. of Informatics, University of Oslo

+4791880522

http://dhis2.org


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


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


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