dhis2-users team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Marta,
I would be interested to hear what others say, but I think there are
two possibilities.

1) Use category combinations with three categories
a) IPD/OPD
b) All possible levels (Chrirurgie, Maternité, etc). Some of these
will overlap  IPD - Maternité and  OPD - Maternité, while others will
never be used from the looks of your list (i.e. IPD - SMI-GYN )
c) Gender. Again, some of these will never be used (IPD -
Maternité-Male) for example.

Problem with this approach is that
1 )you will have many category option combos which will never be used, and
2) Altering category combos can be very tricky. There are a number of
long-standing bugs when it comes to adding new category options, and
them not being available. There are ways around this, but it requires
use of the Web API /or database to manually create the new category
option combos, which are not created in spite of adding new category
options.

Advantages with this approach obviously are that you would only need a
few data elements to represent all possible combinations, but only a
few of those operands you would actually ever enter data for.

Second approach obviously is to use many different data elements, with
as you say ,only gender as a single category combo. I might prefer
this approach.

Third approach would be as you say to dis-aggregate the orgunits. This
will really complicate potentially the orgunit hierarchy as you note.
We have observed a pretty severe penalty on performance (with the
datamart operations) as the number of orgunits increases by
potentially an order of magnitude or more, if you separate out all of
the different service levels. It also complicates the data entry a
bit, although this could potentially be solved with the use of the new
multi-orgunit data entry forms. I think it also complicates the
analysis a bit because it is simple with the pivot tables to slice out
particular data element operands. It can also be done with orgunit
groups sets however as well.

I would probably tend to go with the second option, namely use of the
simple category option combo with multiple data elements for a single
orgunit. It is not a big deal to create many data elements,
particularly if you can automate their creation by use of the WebAPI.

Regards
Jason




On 9/26/13, Marta Vila <martavila@xxxxxxxxx> wrote:
> Dear all,
>
>       we are trying to figure out the best way to "structre" an HIS in
> dhis2 and would like to share our case with the community.
>
>
> There it goes...
>
> We need to collect several data sets from some the hospital departments.
>
> IPD - Chrirurgie
>  IPD - Maternité
>  IPD - Médécins
>  IPD - Pediatrie
>  OPD - Adultes
>  OPD - Médécins
>  OPD - Pediatrie
>  OPD - SMI-GYN
> OPD - Soins
>
> Lets use *Diagnosis form *and *Cases of Malaria* data element for this
> example.
>
> Then all the departments should fill in the Diagnosis form and we want to
> know the cases of malaria of the 9 departments.
>
> My first approach was to create one org unit per department, and one data
> set for the Diagnosis form.... but i feel it could complicate a bit too
> much the hierarchy and also make a very dynamic use of it (new departments,
> departments closed...)
>
> Other option would be create one unique org unit (hospital) and a different
> data sets for every department... but this would imply creating every data
> element as many time as departments are in the hospital (9 in this example)
> and having to create more every time a new department is included in the
> HIS.
>
> Or... create IPD and OPD under hospital... and then every data element as
> many times as specialities are (7 in this example)
>
> I don't use categories because i want them for gender and age...
>
> None of these options seem perfect to me... so...
> If I got to explain myself and someone already has gone through this... I
> would appreciate to know from your experience :)
>
> Thanks!
>
> Marta
>


-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+260974901293