dhis2-users team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

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