How to structure information?

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 :slight_smile:

Thanks!

Marta

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@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 :slight_smile:

Thanks!

Marta

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

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

  1. Compare information from different health institutions at regional level.

  2. 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.pickering@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

  1. 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@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 :slight_smile:

Thanks!

Marta

Jason P. Pickering

email: jason.p.pickering@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


Dr. Subodha Manoj

Medical Officer - Health Information

Office of the Secretary of Health

Ministry of Health - Sri Lanka.

I think we are not getting any more feedback :slight_smile:

Thanks Jason, Subodha… better late than never they say!!

···

On 3 October 2013 07:58, subodha manoj subodha.manoj@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

  1. Compare information from different health institutions at regional level.
  1. 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).
  1. 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.
  1. 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.pickering@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

  1. 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@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 :slight_smile:

Thanks!

Marta

Jason P. Pickering

email: jason.p.pickering@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

Dr. Subodha Manoj

Medical Officer - Health Information

Office of the Secretary of Health

Ministry of Health - Sri Lanka.

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

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” larshelge@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

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 olati@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” larshelge@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

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 olati@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” larshelge@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