I think we are not getting any more feedback :) Thanks Jason, Subodha... better late than never they say!!
On 3 October 2013 07:58, subodha manoj <[email protected]> wrote: > Hi, > We have a similar situation in Health Institution Performance and Facility > Information System (healthnet.health.gov.lk). Case is to 1. collect and > compare information from different units (surgical unit 1, Surgical unit 3) > at health institution level (some hospitals have about 80 different units > )and to > 2. Compare information from different health institutions at regional > level. > 3. Additionally number of admissions collected under male, female and > under 12 groups. > > Refer the attached screen shot. > > In that every column is a data element. > Every row is a category option. > > Reasons for selection this approach > > 1. When a caregory combination used (type of ward and type of admission) > it created many useless combinations like medical officer in surgical unit > 1 who are female. (do not know how to avoid this). > > 2. When type of admission is used as a category option, cannot filter the > number of admissions without creating an indicator for each unit (surgical > unit 1) at the health institution level comparison. > > 3. Selected approach balance the two (I guess :)) > a. without creating cumbersome indicators unit comparison is possible at > Hospital level and regional level. > b. one indicator can filter total number of admissions at the institution > level > c. System is not too complex to manage (one data element is having limited > number of options) > > > Does anyone think this as a reasonable approach ? > > > On Thu, Sep 26, 2013 at 1:35 PM, Jason Pickering < > [email protected]> wrote: > >> 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 <[email protected]> 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: [email protected] >> tel:+260974901293 >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-users >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~dhis2-users >> More help : https://help.launchpad.net/ListHelp >> > > > > -- > Dr. Subodha Manoj > Medical Officer - Health Information > Office of the Secretary of Health > Ministry of Health - Sri Lanka. >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-users More help : https://help.launchpad.net/ListHelp
