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?
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 !
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?
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
···
On 22 September 2011 11:40, Abyot Gizaw <abyota@gmail.com> wrote:
Abyot.
On Thu, Sep 22, 2011 at 11:25 AM, Bob Jolliffe <bobjolliffe@gmail.com> > 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?
I think "bootstrapping" with most popular concepts make sense here. We
are not really tying anyone's hands, just offering some standard
options, one can always remove or add new ones.
Seriously though, whether this is done internally (ie from inside the
distributed war) or externally is not a major decision we have to make
now. What I'd still like is some suggestions around what might be in
a core set of useful concepts. I've had one suggestion which is
"nothing at all" That's an easy one to deliver. Any others? Maybe
its too early to ask this before we see some functionality.
In defence of external bootstrapping kits, one could better address
i18n concerns this way.
···
On 22 September 2011 16:26, Knut Staring <knutst@gmail.com> wrote:
Regards, Knut (via mobile phone)
On Sep 22, 2011 5:13 PM, "Abyot Gizaw" <abyota@gmail.com> wrote:
I take bootstrapping at implementation level than at design level
2011/9/22 Lars Helge Øverland <larshelge@gmail.com>
I think "bootstrapping" with most popular concepts make sense here. We
are not really tying anyone's hands, just offering some standard
options, one can always remove or add new ones.
I personally find this a bit of an academic discussion. From an implementation standpoint having concepts like Gender pre-defined seems to make a lot of sense to me. This is sort of like saying, we should not have pre-defined periods (which we do), and it would be up to the user to define them (although they should be essentially self-obvious and defining them has been proven in the field to be very painful). Having some really basic and well accepted concepts (and I would go as far as data elements, such as “Population”) would be very useful. We cannot argue about gender and some other concepts which are essentially universal in almost all implementations of DHIS2 to date. One of the big problems from an implementation standpoint is that when new users attempt to use DHIS, it is blank. There is nothing there. We have tried to fill this gap a bit with documentation, but having a set of predfined concepts (or data elements or periods or even orgunits a la HealthMapper), would certainly not hurt. If there are purists who want to delete them and start over, they should be more than free to do so. However, if it eases the standardization with other systems or whatever Bob is attempting to do (which I am sure it would), I see no harm in it.
Nonetheless, I do not want us to get distracted by this. The real task at hand is fixing the data element/category logic, which we know has limitations and which implementers (such as myself) have had to struggle with. I have been a strong critic of the business logic, while believing the model is not far off (although I do believe having a hierarchical and transient association is eventually going to be necessary). Once we realize that there is not much difference between an orgunit, and period and a data element/category option, the better and simpler it will be for both developers and implementers.
I think “bootstrapping” with most popular concepts make sense here. We
are not really tying anyone’s hands, just offering some standard
options, one can always remove or add new ones.
From an implementation standpoint having concepts like Gender pre-defined seems to make a lot of sense to me. This is sort of like saying, we should not have pre-defined periods (which we do), and it would be up to the user to define them (although they should be essentially self-obvious and defining them has been proven in the field to be very painful). Having some really basic and well accepted concepts (and I would go as far as data elements, such as “Population”) would be very useful. We cannot argue about gender and some other concepts which are essentially universal in almost all implementations of DHIS2 to date. One of the big problems from an implementation standpoint is that when new users attempt to use DHIS, it is blank. There is nothing there. We have tried to fill this gap a bit with documentation, but having a set of predfined concepts (or data elements or periods or even orgunits a la HealthMapper), would certainly not hurt. If there are purists who want to delete them and start over, they should be more than free to do so. However, if it eases the standardization with other systems or whatever Bob is attempting to do (which I am sure it would), I see no harm in it.
Nonetheless, I do not want us to get distracted by this. The real task at hand is fixing the data element/category logic, which we know has limitations and which implementers (such as myself) have had to struggle with. I have been a strong critic of the business logic, while believing the model is not far off (although I do believe having a hierarchical and transient association is eventually going to be necessary). Once we realize that there is not much difference between an orgunit, and period and a data element/category option, the better and simpler it will be for both developers and implementers.
I think “bootstrapping” with most popular concepts make sense here. We
are not really tying anyone’s hands, just offering some standard
options, one can always remove or add new ones.
Hi all,
I would like add a little stone to the building...
I thank that that we may use a mix of both concepts. Let DHIS come completly to let the imagination of the designer free to create ways of using the tool or imagine new designs to meet his specific plementation needs. In addition to that as Bob is proposing we may give option to load some pre-configuration settings via dxf files. You could have for instance:
- community base template
- GIS centric templates
- WHO indicators centric templates
- etc.
An we could allow implementers to share their custom configurations on DHIS2 websites as we do with firefox ad dons.
I think that this way the flexibility of the tool will be preserved and the design process could be speed up a little bit depending on the needs.
Regards
Romain
···
Sent from my BlackBerry® smartphone. Provided by MTN CI
-----Original Message-----
From: Bob Jolliffe <bobjolliffe@gmail.com>
Sender: dhis2-devs-bounces+romain=tohouri.com@lists.launchpad.net
Date: Thu, 22 Sep 2011 16:42:40
To: Knut Staring<knutst@gmail.com>
Cc: dhis2-devs<dhis2-devs@lists.launchpad.net>
Subject: Re: [Dhis2-devs] survey of existing concepts
On 22 September 2011 16:26, Knut Staring <knutst@gmail.com> wrote:
Designing to enable bootstrapping
Or is that bootstrapping to aid designing
Seriously though, whether this is done internally (ie from inside the
distributed war) or externally is not a major decision we have to make
now. What I'd still like is some suggestions around what might be in
a core set of useful concepts. I've had one suggestion which is
"nothing at all" That's an easy one to deliver. Any others? Maybe
its too early to ask this before we see some functionality.
In defence of external bootstrapping kits, one could better address
i18n concerns this way.
Regards, Knut (via mobile phone)
On Sep 22, 2011 5:13 PM, "Abyot Gizaw" <abyota@gmail.com> wrote:
I take bootstrapping at implementation level than at design level
2011/9/22 Lars Helge Øverland <larshelge@gmail.com>
I think "bootstrapping" with most popular concepts make sense here. We
are not really tying anyone's hands, just offering some standard
options, one can always remove or add new ones.
but poor me still not happy 