I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
···
**Martin Van Aken - **Freelance Enthusiast Developer
Can you share the frequency of change or required frequency that you would have to maintain if you choose to create a data element and dataset for this case, because its the most viable and given ability to track changes over time. This could be a data set only assigned to one Orgunits.
Also how often to use this in analysis, this can also guide on on the dataset frequency.
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
It seems like your frequency is 6 monthly in which case you can set up a dataset with that frequency or any other you choose and then create a csv import file with all your facilities in, currect period, data element and value (just copy the same value for every facility and import. Keep the csv and every frequency you need to just change the period and value and possibly check you dont have new reporting units and import the same file.
You can create similar xml or json imports but csv seems easier.
Maybe this could work for you?
Elmarie Claasen
HISP-SA
This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
Thanks for your reply and proposal - my example was just that - an example. I don"t have fixed periodicity for changes (else I agree that it could be easy to setup a set with the given periodicity). I keep the csv import idea, could actually be useful in other cases I’m facing.
Thanks and regards,
Martin
···
On Tue, Aug 30, 2016 at 11:03 PM, Elmarie Claasen elmarie@hisp.org wrote:
Hi Martin,
It seems like your frequency is 6 monthly in which case you can set up a dataset with that frequency or any other you choose and then create a csv import file with all your facilities in, currect period, data element and value (just copy the same value for every facility and import. Keep the csv and every frequency you need to just change the period and value and possibly check you dont have new reporting units and import the same file.
You can create similar xml or json imports but csv seems easier.
Maybe this could work for you?
Elmarie Claasen
HISP-SA
This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
The problem is that it all depends - those are linked to changes at the health program manager level, and it’s not a predictable variable. The problem is that it’s stable-ish - for a given month, it will be stable for a most facilities, but there will probably be changes for a set of facilities each month or tow (in other words: at least one subset/group of facilities will have a change every period of two - not the same group each time of course).
So, the dataSet frequency is not stable - can stay stable for six months, then change twice in the next three, etc.
Thanks already for your help,
Martin
···
On Tue, Aug 30, 2016 at 10:53 AM, Prosper BT ptb3000@gmail.com wrote:
Dear Martin,
Can you share the frequency of change or required frequency that you would have to maintain if you choose to create a data element and dataset for this case, because its the most viable and given ability to track changes over time. This could be a data set only assigned to one Orgunits.
Also how often to use this in analysis, this can also guide on on the dataset frequency.
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
This is more like an event. You can model it as a program without registration and then create program indicators which can be used in aggregate (more like a constant from an event). However this depends on how creative you will be to ensure the periodicity is maintained.
Alex
···
On Tue, Aug 30, 2016 at 10:53 AM, Prosper BT ptb3000@gmail.com wrote:
Dear Martin,
Can you share the frequency of change or required frequency that you would have to maintain if you choose to create a data element and dataset for this case, because its the most viable and given ability to track changes over time. This could be a data set only assigned to one Orgunits.
Also how often to use this in analysis, this can also guide on on the dataset frequency.
Regards
–
**Martin Van Aken - **Freelance Enthusiast Developer
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
good question. There is no perfect solution at this point. I assume you need these values for analytics. This means that the best solution is likely:
Find and use the lowest common period type (frequency) for which data will change (I assume Quarterly)
Store the RBF specific data in an external data source, e.g. using data store, where you can store the Quarter, data element (Consultation Price) and value. You can write a front end app that provides a user-friendly interface to this data.
Generate values for all org units. You can write code in your component to keep this data in check, e.g. every time someone changes a value in your RBF data source/app, then automatically generate/populate data values accordingly in DHIS 2.
This is admittedly a bit painful, but its not too bad, and it gives you the benefit that all analytics features of DHIS 2 will just work (indicators, dashboards and so on).
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
Thanks a lot for your detailed answer. This is the direction we were aiming, but I wanted confirmation that it was “the good way”. Not that painful on our side, as we do have an external app which could generate the values using DHIS2 API.
Thanks and congrats again by the way for an API that 1/ allow us to do everything that the UX can 2/ is documented 3/ work.
Our goal is exactly what you outlined - even if it does not change often, we want the prices to be available for analytics, hence they need to be data elements.
Regards,
Martin
···
On Fri, Sep 2, 2016 at 7:25 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Martin,
good question. There is no perfect solution at this point. I assume you need these values for analytics. This means that the best solution is likely:
Find and use the lowest common period type (frequency) for which data will change (I assume Quarterly)
Store the RBF specific data in an external data source, e.g. using data store, where you can store the Quarter, data element (Consultation Price) and value. You can write a front end app that provides a user-friendly interface to this data.
Generate values for all org units. You can write code in your component to keep this data in check, e.g. every time someone changes a value in your RBF data source/app, then automatically generate/populate data values accordingly in DHIS 2.
This is admittedly a bit painful, but its not too bad, and it gives you the benefit that all analytics features of DHIS 2 will just work (indicators, dashboards and so on).
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer
Thanks a lot for your detailed answer. This is the direction we were aiming, but I wanted confirmation that it was “the good way”. Not that painful on our side, as we do have an external app which could generate the values using DHIS2 API.
Thanks and congrats again by the way for an API that 1/ allow us to do everything that the UX can 2/ is documented 3/ work.
Our goal is exactly what you outlined - even if it does not change often, we want the prices to be available for analytics, hence they need to be data elements.
Regards,
Martin
–
On Fri, Sep 2, 2016 at 7:25 PM, Lars Helge Øverland lars@dhis2.org wrote:
Hi Martin,
good question. There is no perfect solution at this point. I assume you need these values for analytics. This means that the best solution is likely:
Find and use the lowest common period type (frequency) for which data will change (I assume Quarterly)
Store the RBF specific data in an external data source, e.g. using data store, where you can store the Quarter, data element (Consultation Price) and value. You can write a front end app that provides a user-friendly interface to this data.
Generate values for all org units. You can write code in your component to keep this data in check, e.g. every time someone changes a value in your RBF data source/app, then automatically generate/populate data values accordingly in DHIS 2.
This is admittedly a bit painful, but its not too bad, and it gives you the benefit that all analytics features of DHIS 2 will just work (indicators, dashboards and so on).
best,
Lars
–
**Martin Van Aken - **Freelance Enthusiast Developer
I’m wondering about the best way to manage a use case of ours in DHIS2. We have a specific element of data (prices for services in an RBF system) which is normally the same for every org unit for a given period (and in most case stable for several periods). As an example, we could have something like:
Consultation Price:
Jan-December 2016: 2.5$
Jan-June 2016: 2$
July-December 2016: 3$
I’m not sure what to use to represent this kind of data in DHIS2:
Constant is not good as it can evolve
Standard Data Element means that when we make a change, we need to “apply” it to every entity for the given period (thus generating hundreds or thousand of copies of that values)
Added question: if we go for a Data Element, how could we “fill it” at regular basis (like for the next period each time) - we don’t want people to fill as a data entry for individual entities (it does not make any sense, and it’s not something they “report” anyway).
Any opinion is welcome!
Martin
–
**Martin Van Aken - **Freelance Enthusiast Developer