Re: [Dhis2-users] How to structure information?

2013-10-31 Thread Ola Hodne Titlestad
Hi,

Agree with Lars. I would use orgunits to represent the departments/wards as
it gives you more flexibility. It will require more customisation time to
get all the orgunit names right in each hospital, but it is worth it, at
least if you want to support data analysis and mangement at each hospital.

Sometimes the hospital prefers to use local names on wards, like Cot ward
A. Cot ward B, up/down etc and also have more than one physical ward/room
for the same type/category.  A standard naming scheme through data element
categories would be difficult to use in this case.

Typically a hospital would like to do analysis by each physical ward (bed
occupancy rates etc) and not always group them together by type of ward.

You can use orgunit groups to apply standard hospital departement names to
all those wards,  which can then be used for aggregation when doing
analysis above the hospital level or when comparing hospitals.

Ola
--
On 31 Oct 2013 09:32, Lars Helge Øverland larshe...@gmail.com wrote:

 Hi Marta,

 I don't know enough about the use-case to be sure. However my suggestion
 would be to use the organisation units to represent the departments. It is
 simply because usually the departments are different across hospitals -
 some are not always there, some are combined and so on. So you could make a
 script that creates the initial setup with all departments in all places
 and then modify it from there. It makes form design easier. The data mart
 performance penalty mentioned above applied at the time of writing but not
 anymore with the analytics engine. A problem with using categories is that
 you get lots of non-applicable fields if you use section forms, and lots of
 maintenance mess if you go with custom forms.

 cheers

 Lars


 ___
 Mailing list: https://launchpad.net/~dhis2-users
 Post to : dhis2-users@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~dhis2-users
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp


Re: [Dhis2-users] How to structure information?

2013-10-31 Thread Bal Ram Bhui
Hi Ola and Lars,
Thank you guys for very much for working so hard to meet our requests. I have 
some observations and suggestions for you; I am not sure if they are covered in 
DHIS 2.13. I have just talked with Stephen about it and we are going to test it 
for Liberia.

My observation is on data visualizer. I see that we can use data element as 
filter but the indicator while taking period as category for the line graph. I 
think we need to be able to see the indicator graphs by organization unit or 
and group set. Other observation is that is it possible to give clearly 
different markers on the lines of graph in addition to the colors which is 
there now so that they can be distinguishable even when they are printed.

Thanks a million.
Bal Ram Bhui
Monrovia.



On Thursday, October 31, 2013 9:07 AM, Ola Hodne Titlestad ol...@ifi.uio.no 
wrote:
 
Hi, 
Agree with Lars. I would use orgunits to represent the departments/wards as it 
gives you more flexibility. It will require more customisation time to get all 
the orgunit names right in each hospital, but it is worth it, at least if you 
want to support data analysis and mangement at each hospital. 
Sometimes the hospital prefers to use local names on wards, like Cot ward A. 
Cot ward B, up/down etc and also have more than one physical ward/room for the 
same type/category.  A standard naming scheme through data element categories 
would be difficult to use in this case. 
Typically a hospital would like to do analysis by each physical ward (bed 
occupancy rates etc) and not always group them together by type of ward.
You can use orgunit groups to apply standard hospital departement names to all 
those wards,  which can then be used for aggregation when doing analysis above 
the hospital level or when comparing hospitals. 
Ola
--
On 31 Oct 2013 09:32, Lars Helge Øverland larshe...@gmail.com wrote:

Hi Marta,


I don't know enough about the use-case to be sure. However my suggestion would 
be to use the organisation units to represent the departments. It is simply 
because usually the departments are different across hospitals - some are not 
always there, some are combined and so on. So you could make a script that 
creates the initial setup with all departments in all places and then modify 
it from there. It makes form design easier. The data mart performance penalty 
mentioned above applied at the time of writing but not anymore with the 
analytics engine. A problem with using categories is that you get lots of 
non-applicable fields if you use section forms, and lots of maintenance mess 
if you go with custom forms.


cheers


Lars
 
___
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~dhis2-users
Post to     : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp___
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp


Re: [Dhis2-users] How to structure information?

2013-10-31 Thread Marta Vila
Thank you Lars, Ola,

it really seems the best approach.  I will keep it in mind. I remember
struggling in India with department names and so on... and it was really a
headache, better to falicitate it as much as possible.

And categories... i preffer to save them for its actual use... since
gender and age are very likely to be requested in forms...

thanks again!
cheers


On 31 October 2013 10:07, Ola Hodne Titlestad ol...@ifi.uio.no wrote:

 Hi,

 Agree with Lars. I would use orgunits to represent the departments/wards
 as it gives you more flexibility. It will require more customisation time
 to get all the orgunit names right in each hospital, but it is worth it, at
 least if you want to support data analysis and mangement at each hospital.

 Sometimes the hospital prefers to use local names on wards, like Cot ward
 A. Cot ward B, up/down etc and also have more than one physical ward/room
 for the same type/category.  A standard naming scheme through data element
 categories would be difficult to use in this case.

 Typically a hospital would like to do analysis by each physical ward (bed
 occupancy rates etc) and not always group them together by type of ward.

 You can use orgunit groups to apply standard hospital departement names to
 all those wards,  which can then be used for aggregation when doing
 analysis above the hospital level or when comparing hospitals.

 Ola
 --
 On 31 Oct 2013 09:32, Lars Helge Øverland larshe...@gmail.com wrote:

 Hi Marta,

 I don't know enough about the use-case to be sure. However my suggestion
 would be to use the organisation units to represent the departments. It is
 simply because usually the departments are different across hospitals -
 some are not always there, some are combined and so on. So you could make a
 script that creates the initial setup with all departments in all places
 and then modify it from there. It makes form design easier. The data mart
 performance penalty mentioned above applied at the time of writing but not
 anymore with the analytics engine. A problem with using categories is that
 you get lots of non-applicable fields if you use section forms, and lots of
 maintenance mess if you go with custom forms.

 cheers

 Lars


 ___
 Mailing list: https://launchpad.net/~dhis2-users
 Post to : dhis2-users@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~dhis2-users
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp


Re: [Dhis2-users] How to structure information?

2013-10-30 Thread Marta Vila
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 subodha.ma...@gmail.com 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 
 jason.p.picker...@gmail.com 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 martav...@gmail.com 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 

[Dhis2-users] How to structure information?

2013-09-26 Thread Marta Vila
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
___
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp


Re: [Dhis2-users] How to structure information?

2013-09-26 Thread Jason Pickering
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 martav...@gmail.com 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.picker...@gmail.com
tel:+260974901293

___
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help   : https://help.launchpad.net/ListHelp