How to best implement registries

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.

image

···

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards

···

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards

···

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

Lars

···

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hi Knut,

How you are manage ‘oral medicine’, ‘findings’ (13 and 14) in your data sheet ?
In one event one patient may have 2 , 3 or more medicine , Are we able do this in DHIS2 ?

Regards,

Sumudu Weerasinghe

···

On Mon, Nov 23, 2015 at 4:51 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh

Event capture Bangladesh.docx (232 KB)

···

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

···

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Sumudu,

In this case you may choose to create more than one data element to cater for the different medications like

Medicine 1

Medicine 2

Medicine 3

Medicine 4…

Regards

···

On Mon, Nov 23, 2015 at 4:31 PM, sumudu weerasinghe sumuduw00@gmail.com wrote:

Hi Knut,

How you are manage ‘oral medicine’, ‘findings’ (13 and 14) in your data sheet ?
In one event one patient may have 2 , 3 or more medicine , Are we able do this in DHIS2 ?

Regards,

Sumudu Weerasinghe


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

On Mon, Nov 23, 2015 at 4:51 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan

···

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Hannan,

I can understand the pain of upgrading and change management. Obviously between 2.13 and 2.20 there have been major changes in the tracker.

Since its a small tracker program with few data elements, would you rather take the option of rebuilding everything from scratch on 2.20, then prepare the data from previous versions and re-import?

Regards

···

On Tue, Nov 24, 2015 at 11:10 AM, Hannan Khan hannank@gmail.com wrote:

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Hi Hannan,

Sorry that I haven’t responded. can you please remind us what was reported - I can see this bug https://bugs.launchpad.net/dhis2/+bug/1492967

Do you have more?

···

On Tue, Nov 24, 2015 at 9:10 AM, Hannan Khan hannank@gmail.com wrote:

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan


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,

Abyot.

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Prosper

In tracker we have large amount of data, as we are using tracker from introduction of the tracker in DHIS2. And the data conversion is a major problem for us.

Major significant change in tracker is in ‘Patient Attribute’ and system generated ‘Patient Identifier’ and is the major problem for us. System generated ‘Patient Identifier’ was used as Heath ID for our patient as there is no national level universal patient identifier in Bangladesh. All our field staffs are using this as a unique identifier. When that is dropped in 19 is a major issue for us. This was reported by my team but not yet get any solution from the team. Lars and Abyot’s special attention is required.

Regards

Hannan

···

On Tue, Nov 24, 2015 at 2:57 PM, Prosper BT ptb3000@gmail.com wrote:

Dear Hannan,

I can understand the pain of upgrading and change management. Obviously between 2.13 and 2.20 there have been major changes in the tracker.

Since its a small tracker program with few data elements, would you rather take the option of rebuilding everything from scratch on 2.20, then prepare the data from previous versions and re-import?

Regards

On Tue, Nov 24, 2015 at 11:10 AM, Hannan Khan hannank@gmail.com wrote:

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Abyot

Yes that is a small one. The major problem creator is in the attachment.

Regards

Hannan

HISP Bangladesh​​

Gmail - Bangladesh Tracker data conversion.pdf (71.6 KB)

···

On Tue, Nov 24, 2015 at 2:58 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Hannan,

Sorry that I haven’t responded. can you please remind us what was reported - I can see this bug https://bugs.launchpad.net/dhis2/+bug/1492967

Do you have more?


Thank you,

Abyot.

On Tue, Nov 24, 2015 at 9:10 AM, Hannan Khan hannank@gmail.com wrote:

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan


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

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Dear Hannan,

This is related to DHIS2 being able to generate unique codes with customized parameters e.g FacilityCodeOrgunitNumberXXXXX.

A good use case of this is the outbreak code (for tracking outbreaks - it depends on facility/district /disease/ period (weekNo)).

I support the idea. May be the unique identifier needs to be re-modelled to be generic so that it can be attached to surveillance rules, events, etc.

Alex

···

On Tue, Nov 24, 2015 at 1:01 PM, Hannan Khan hannank@gmail.com wrote:

Dear Abyot

Yes that is a small one. The major problem creator is in the attachment.

Regards

Hannan

HISP Bangladesh​​


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

On Tue, Nov 24, 2015 at 2:58 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Hannan,

Sorry that I haven’t responded. can you please remind us what was reported - I can see this bug https://bugs.launchpad.net/dhis2/+bug/1492967

Do you have more?


Thank you,

Abyot.

On Tue, Nov 24, 2015 at 9:10 AM, Hannan Khan hannank@gmail.com wrote:

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan


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

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "

Dear Hannan,

Unique ID is quite tricky. In an ideal situation, it is better unique ID is generated outside DHIS2 and feed to it.

The thing is we don’t have a mechanism to tell DHIS2 how the ID should be generated. Yes, we used to have a something that worked before - but it was not-scalable.

Currently there is a discussion going on among developers here. We are planning to introduce a model where one can specify a pattern of the unique ID and the system will generate accordingly - we hope to have this for 2.23.

···

On Tue, Nov 24, 2015 at 11:01 AM, Hannan Khan hannank@gmail.com wrote:

Dear Abyot

Yes that is a small one. The major problem creator is in the attachment.

Regards

Hannan

HISP Bangladesh​​


Thank you,

Abyot.

On Tue, Nov 24, 2015 at 2:58 PM, Abyot Gizaw abyota@gmail.com wrote:

Hi Hannan,

Sorry that I haven’t responded. can you please remind us what was reported - I can see this bug https://bugs.launchpad.net/dhis2/+bug/1492967

Do you have more?


Thank you,

Abyot.

On Tue, Nov 24, 2015 at 9:10 AM, Hannan Khan hannank@gmail.com wrote:

Dear Prosper

Yes you are right; new versions have some very good feature (Thanks to Lars and the Team) which meet majority of the requirements and some are done through discussion and alternative reporting.

But converting from 13 to 21 is a big headache; we already done some conversion from 13 to 19 but still there are some bugs already reported and waiting for Abyot’s response and I ask the Team to take our request seriously, because we are under huge pressure from the MoH and development partners. Also we face a lot of new issues due to huge data volume.

Also orient large number of user on this new UI is another big issue.

Hope we can soon upgrade one of the Biggest tracker to version 2.21

Regards

Hannan


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

On Tue, Nov 24, 2015 at 12:31 PM, Prosper BT ptb3000@gmail.com wrote:

Hi Hannan,

Good to read from you hoping Bangladesh is treating you well.

You can now use program indicators and create majority of the donor statistics, however you will need to upgrade to the latest versions atleast 2.20 or 2.21. You also need to have options sets to make meaningful indicator expressions.

These program indicators will be used in pivot table, data visualizer…

I think using 2.13 you are still using category combinations for option sets, am not sure how they are supported in indicators because I have not used them. You may need to overhaul the current 2.13 version to 2.20 and import the data with new options sets if you are using them.

Regards

On Tue, Nov 24, 2015 at 7:44 AM, Hannan Khan hannank@gmail.com wrote:

Dear Knut

Fully agree with Lars and Prosper.

In our case we used ‘Single Event without registration’ (in version 2.13) and now ‘Event capture’. But producing report using aggregation query is a headache as Donor requirements are varied widely. SO if you have any idea share it with us. I attached our screenshot.

Regards

Hannan Khan

HISP Bangladesh


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


Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb

On Mon, Nov 23, 2015 at 5:21 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi,

yes for it to be valuable then disease and treatment must be coded (based on option sets).

A major benefit of using events is that the age group aggregates could be produced ad-hoc using program indicators. So this will remove the need for pre-defined age groups. As we know these are hard to agree on, never consistent between countries and donors and always change over time, making them painful to manage.

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

On Mon, Nov 23, 2015 at 10:37 AM, Kamugunga Adolphe kaadol@gmail.com wrote:

Dear Knut,
The program without registration could fit in case they simply want to record cases/services provided on daily basis. Name should be dropped for ethical issues and rely only on the Reg. But if database could support data quality audit exercises, serial number could help to locate patients files, and selection boxes should the best to minimize typing/spelling errors

Regards


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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Adolphe Kamugunga
MIS Technical Advisor
Knowledge Management, Data Use and Research
Rwanda Health System Strengthening Activity
Management Sciences for Health
Rwanda-Kigali
Mobile: +250 788 740 578
Email:kaadol@gmail.com
Skype: ka.adolphe

Stronger health systems. Greater health impact.

On 22 November 2015 at 06:34, Prosper BT ptb3000@gmail.com wrote:

Dear Knut,

If the purpose of data collection is for reporting through counts of number visiting and services in a given period and no interest in longitudinal follow up then they can go without registration.

And as you suggest for non numeric data elements (findings, medicine…) need option sets, to build program indicators to be used on dashboard.

Regards


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

On Sun, Nov 22, 2015 at 3:27 AM, Knut Staring knutst@gmail.com wrote:

Hello,

Please see the attached “line listing” case registry form for outpatients at frontline clinics. Typically, this is the layout of big registry books located at rural health centres and sub-centres. I suppose the date and serial number would not be needed when moving from paper to tablets.

My intuitive sense is that this should be implemented as a program without registration, and just one single stage. Most of the fields should be free text or option sets (in the case of Yes/No that is a data type).

Then it will be important to generate aggregate data based on this, which I assume means we do need drop down lists/option sets for all diseases and treatments.

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Just wanted to see if people had different ideas and suggestions, as this is becoming a pretty typical use case for Tracker.


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

Prosper Behumbiize, MPH
Global HISP| University Of Oslo/HISP Uganda
+256 752 751 776 | +256 776 139 139

ptb3000@gmail.com | prosper@dhis2.org | Skype: prospertb