dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 22 September 2011 11:40, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
> Bob - thank you for making me happy :)  but poor me still not happy :(
>
> The thing is - I am against this idea of setting a path of (pre)configuring
> in dhis2.
>
> The strength of dhis2, and for me the key for it being used in multiple
> countries, is that it makes no particular assumptions about any practice or
> context. It only provides resources (the objects, the gui, the language,...
> and now the attribute thing) so that users design (I don't want to use the
> term configure here - because for me what users are doing is more than
> configuration) what they think is appropriate in their contexts. This for me
> has brought greater degree of flexibility and transportability for dhis2.
> And if we kind of embark on issues of (re)configuration, I am afraid we will
> undermine the flexibility/transportability capacity of dhis2.
>
> Well one might say it is only at the db level, we can remove that and start
> empty..... I don't know and I am not sure whether discussions of codifing
> those repeatedly appearing issues/concepts will not popup some where down
> the line.  I feel we should deliberately avoid issues of configurations !

OK.  I think there are advantages and disadvantages of pre-configuring
such things.  Personally I can see some advantage of having some
commonly used concepts in place and maybe even some standard
categoryoptions (Male, Female, Unknown, Not Applicable, Yes, No etc)
for the simple purpose of making the user design process less onerous
and perhaps even some guidance of good practice.  I say perhaps here
because I am cautious of prescribing what is and is not be good
practice and aware that good practice in one context may not be good
practice in another.  I think even in terms of AGE_GROUPs we probably
have a good idea of a set of most commonly used ones by now.  Which is
not to say that users cannot freely create as before.

It could be done differently.  A brand new out-of-the-box dhis2
install could come completely blank (except we would still need an
UNCLASSIFIED concept, in much the same way we need default
cateogoryoptioncombo).  And users have the option of installing a
'starter pack' from dhis2.org via dxf if they choose to.   In fact
that might be a cleaner separation.

Regards
Bob

> Abyot.
>
> On Thu, Sep 22, 2011 at 11:25 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> wrote:
>>
>> Greetings.  I am busy trying to implement concept mapping of
>> categories and groupsets in dhis and looking for some input from our
>> wide and varied experience.  The reason being that I want to assemble
>> some pre-defined core concepts to make it easier for users to start
>> (re)configuring a system.
>>
>> For example, one concept which is essential is the UNCLASSIFIED
>> concept.  When an existing database is loaded then obviously none of
>> the existing categories or categoryoptions will be classified.  And
>> all constraints must be relaxed on these, meaning that any
>> unclassified categoryoption may be used in any unclassified category.
>> (Abyot this should make you happy - if you choose not to classify
>> anything then you are effectively back to your free-for-all
>> situation).
>>
>> But there are three significant advantages in classifying these
>> things, eg flagging age related categories and categoryoptions with
>> the AGE_GROUP concept.
>> (i)   user interface simplification.  when picking categoryoptions to
>> assign to a category tagged as AGE_GROUP, ui should only present
>> AGE_GROUP categoryoptions
>> (ii)  pivot table reports - by using the concept as column name rather
>> than the category name(s) we can group all the under 5's, regardless
>> of the category which collected this information.  (Also we can
>> specify 'safe' column names).
>> (iii) we can explicitly specify dimensions of data for import/export
>> purposes
>>
>> So implementoers will be encouraged to set about classifying their
>> existing categories, categoryoptions and groupsets.
>>
>> I want to provide a set of built in concepts to make the process a bit
>> easier.  This is not meant to be an exhaustive list.  The user can
>> always add concepts, but these are meant to be a pre-primed
>> 'starter-pack'.  I can think of a few obvious ones I have come across,
>> like:
>> AGE_GROUP
>> SEX (or GENDER?)
>> DISEASE
>> PREGNANCY_STATUS
>> STOCK
>> LOCATION (this one is a bit wide covering things like in-patient,
>> out-patient, in community etc.  better suggestions welcome)
>> OWNERSHIP
>> FACILITY_TYPE
>>
>> Note the last two are more commonly associated with orgunit groupsets
>> than categories.  Can I ask people to look at the dimension headers of
>> pivot tables they might have, review the list I have above and send me
>> suggestions for additional concepts which occur frequently?
>>
>> Thankss
>> Bob
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>
>