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 <[email protected]> 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 <[email protected]> wrote: > >> Thanks for the thoughts, Jim. Some comments below. >> >> On Sat, Feb 15, 2014 at 2:49 PM, Jim Grace <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> >>>> *Date: *Sat, 15 Feb 2014 16:30:30 +0800 (SGT) >>>> *To: *[email protected]<[email protected]>; Knut Staring< >>>> [email protected]>; Dhis2-users<dhis2-users-bounces+alvin.marcelo= >>>> [email protected]>; [email protected]< >>>> [email protected]> >>>> *ReplyTo: * Brajesh Murari <[email protected]> >>>> *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 < >>>> [email protected]> 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" <[email protected]> >>>> Date: Sat, 15 Feb 2014 07:41:03 >>>> To: Knut Staring<[email protected]>; >>>> Dhis2-users<dhis2-users-bounces+alvin.marcelo= >>>> [email protected]>; [email protected]< >>>> [email protected]> >>>> Reply-To: [email protected] >>>> 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 <[email protected]> >>>> Sender: "Dhis2-users" >>>> <[email protected]>Date: >>>> Sat, 15 Feb 2014 08:16:23 >>>> To: [email protected]<[email protected]> >>>> Subject: [Dhis2-users] Maps of outbreaks >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~dhis2-users >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~dhis2-users >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~dhis2-users >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~dhis2-users >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~dhis2-users >>>> Post to : [email protected] >>>> 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 >> > > -- Knut Staring Dept. of Informatics, University of Oslo +4791880522 http://dhis2.org
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-users More help : https://help.launchpad.net/ListHelp
