dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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 !

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
>