Re: [Dhis2-users] Maps of outbreaks
Hi Bob, Will not get into the semantics here. :-| 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 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 ... :-) > > Bob > > > On 15 February 2014 07:16, Knut Staring 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 >> >> 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 >> >> ___ >> 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
Re: [Dhis2-users] Maps of outbreaks
Hi Alvin, It is always good to use a more diplomatic approach to define 'outbreaks' rather than using a word like 'insurgency' that is I think as you list out the words "outbreaks = outbursts" may be a perfect match. Brajesh Murari wrote: >___ >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
Re: [Dhis2-users] Maps of outbreaks
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 15. feb. 2014 20:06 skrev "Saptarshi Purkayastha" følgende: > 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 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 >> >> >> On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace 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.) >>> >>> Cheers, >>> Jim >>> >>> >>> On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring wrote: >>> Thanks for the thoughts, Jim. Some comments below. On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace 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. >>
Re: [Dhis2-users] Maps of outbreaks
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 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 > > > On Sat, Feb 15, 2014 at 5:40 PM, Jim Grace 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.) >> >> Cheers, >> Jim >> >> >> On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring wrote: >> >>> Thanks for the thoughts, Jim. Some comments below. >>> >>> On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace 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 cho
Re: [Dhis2-users] Maps of outbreaks
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 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.) > > Cheers, > Jim > > > On Sat, Feb 15, 2014 at 10:26 AM, Knut Staring wrote: > >> Thanks for the thoughts, Jim. Some comments below. >> >> On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace 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,
Re: [Dhis2-users] Maps of outbreaks
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 ... :-) Bob On 15 February 2014 07:16, Knut Staring 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 > > 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 > > ___ > 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
Re: [Dhis2-users] Maps of outbreaks
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 wrote: > Thanks for the thoughts, Jim. Some comments below. > > On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace 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" th
Re: [Dhis2-users] Maps of outbreaks
Thanks for the thoughts, Jim. Some comments below. On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace 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 > > > > On Sat, Feb 15, 2014 at 3:42 AM, Alvin B. Marcelo > 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 >> *Date: *Sat, 15 Feb 2014 16:30:30 +0800 (SGT) >> *To: *alvin.marc...@gmail.com; Knut Staring< >> knu...@gmail.com>; Dhis2-users> gmail@lists.launchpad.net>; dhis2-users@lists.launchpad.net< >> dhi
Re: [Dhis2-users] Maps of outbreaks
Hi Alvin On Saturday, 15 February 2014 7:19 PM, Jim Grace 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.) 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 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'. >:-) > >BRajesh > > >Sent from my BB Curve 9320 > > >From: Brajesh Murari >Date: Sat, 15 Feb 2014 16:30:30 +0800 (SGT) >To: alvin.marc...@gmail.com; Knut >Staring; >Dhis2-users; >dhis2-users@lists.launchpad.net >ReplyTo: Brajesh Murari >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 > 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" >Date: Sat, 15 Feb 2014 07:41:03 >To: Knut Staring; >Dhis2-users; >dhis2-users@lists.launchpad.net >Reply-To: alvin.marc...@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 >Sender: "Dhis2-users" >Date: Sat, 15 >Feb 2014 08:16:23 >To: 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 > >___ >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 : d
Re: [Dhis2-users] Maps of outbreaks
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 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 > *Date: *Sat, 15 Feb 2014 16:30:30 +0800 (SGT) > *To: *alvin.marc...@gmail.com; Knut Staring< > knu...@gmail.com>; Dhis2-users gmail@lists.launchpad.net>; dhis2-users@lists.launchpad.net< > dhis2-users@lists.launchpad.net> > *ReplyTo: * Brajesh Murari > *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.marc...@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" > Date: Sat, 15 Feb 2014 07:41:03 > To: Knut Staring; > Dhis2-users gmail@lists.launchpad.net>; dhis2-users@lists.launchpad.net< > dhis2-users@lists.launchpad.net> > Reply-To: alvin.marc...@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 > Sender: "Dhis2-users" > Date: > Sat, 15 Feb 2014 08:16:23 > To: 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 > > ___ > 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 >
Re: [Dhis2-users] Maps of outbreaks
+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 -Original Message- From: Brajesh Murari Date: Sat, 15 Feb 2014 16:30:30 To: alvin.marc...@gmail.com; Knut Staring; Dhis2-users; dhis2-users@lists.launchpad.net Reply-To: Brajesh Murari 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 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" Date: Sat, 15 Feb 2014 07:41:03 To: Knut Staring; Dhis2-users; dhis2-users@lists.launchpad.net Reply-To: alvin.marc...@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 Sender: "Dhis2-users" Date: Sat, 15 Feb 2014 08:16:23 To: 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 ___ 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
Re: [Dhis2-users] Maps of outbreaks
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 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 > Sender: "Dhis2-users" > Date: > Sat, 15 Feb 2014 08:16:23 > To: 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 > > -- 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
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 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" Date: Sat, 15 Feb 2014 07:41:03 To: Knut Staring; Dhis2-users; dhis2-users@lists.launchpad.net Reply-To: alvin.marc...@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 Sender: "Dhis2-users" Date: Sat, 15 Feb 2014 08:16:23 To: 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 ___ 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
