dhis2-devs team mailing list archive

[Jørn Braa <jornbraa@xxxxxxxxx>]

This problem statement is just a consequence of my repeated efforts to
highlight the discrepancy between our handling of data
elements/indicators and how its handled by statisticians (e.g. world
bank, UN and all their "statistical yearbooks and other outlets, those
with background in medical records (because single aggregate from a
EPR will be a calculation of even smaller "atomic" units (e.g. sex and
age))).

As an example; in Malawi we were formulating plans and strategies with
a University of Washington group called ITECH (Bill Lober etc) which
is working for CDC/Pepfar worldwide, i.e. important partner, and which
belongs to the above EPR (or they would say EMR) crowd regarding all
health statisitistics of interest as indicators. As a consequence the
plan for DHIS is Malawi is that of an "indicator repository". Of the
reasons above, I have no problems with that.

A data repository is by definition (if we using that of a data
warehouse) a repository of aggregates from production systems deemed
important or essential by user groups. With other words; a data
repository is by definition based on the "clear
distinctions between "raw counts" and "calculated formulas", by only
containing the latter, based on the "raw counts" from the "production
systems". The different "starting points", i.e. what is a "production
system" and at what level of aggregation does a "production system"
stop, is what causing the confusion between DHIS and others. The data
elements in DHIS are the atomic data units -  in the DHIS, but not in
the world of data!!. All data elements are based on more basic records
and/or counts (the definition of aggregation). As seen from e.g.
OpenMRS, the data elements are therefore already indicators (because
they starts at a more granular level). Hence the term "indicator
repository" for DHIS in Malawi.

The different types of systems are using various points of departure
(the atomic units) for their calculated formulas and aggregations
(DHIS, OpenMRS, World Bank statistics, UNDP annual development report,
etc), but at the other end (output, statistics, reports - what to
display in a GIS) they are all, in principle, at the same level - and
these data are more or less universally called indicators.

This is not more strange than that all we put in the data mart is to
be understand as indicators, and that all that we want to use as
"end-results, for display and reporting, not for further aggregation
in that format, we put in the data mart (or conceptually similar
tables).

As argued before, the quick fix for Knut is to define all he wants to
use for the GIS he defines as indicators using the formula "divided by
one".

 Remember, many of the data elements (raw primary counts) in DHIS are
to be defined as indicators in their own right, e.g. cases of measles,
cholera, yellow fewer, maternal deaths, swine flu etc. maybe more
elegantly displayed in the GIS as dots than as crude numbers. All
things being relative. The level of granularity (as in any part of the
formula) varies.

jorn

On Sat, Nov 14, 2009 at 11:59 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
> In some cases, we would like to import indicator values that have already
> been calculated/estimated through various external procedures. The only
> option here is really to import these as DataElements and DataValues.
> However, this seems to break our logical/philosophical model and the clear
> distinctions between "raw counts" and "calculated forumlas".
> Still, I do think we need to handle them - and be able to display them in
> reports and maps (currently not available for data elements). Such indicator
> values are often based on statistical analyses of survey data etc. and can
> even be for the same kinds of indicators that we calculate inside DHIS.
> How do people feel they should be treated? Should we create a blueprint for
> this?
>
> Knut
>
> _______________________________________________
> 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
>
>