DHIS and logistics management (Was: Re: New requirement from Sri Lanka)

Hi,

Thanks to Thuy for sharing this discussion (see below my email) with all of us on the list.

Over the last month or so we’ve had many requests regarding logistics management or supply chain systems like the one you are describing from Sri Lanka Thuy. It is a burning hot issue it seems and it is good to have some discussions around it and to think collectively on how we can support this in the context of a DHIS implementation.

I commented on this in a recent discussion about similar requirements from Uganda, and I sort of ended up with proposing 3 alternatives to them:

  1. Simplify the requirements and implement it in the current version of DHIS2

  2. Build a new module for basic logistics management in DHIS2

  3. Use an external software solution specialised for logistics management (e.g. the open source alternative OpenLMIS) and make sure you integrate this with DHIS2 both in terms of data exchange and facilitating easy co-installations of both systems.

My advice would be to start with 1), and show what the current DHIS2 can do, and then in parallel start thinking of a more long term solution, 2) or 3).

I think given all the interest in implementing basic logistics management in relation to DHIS2 implementations it might be worth investigating what 2) means in terms of what the requirements are and how much work it would be to do this inside DHIS2.

  1. is of course a little outside our scope, at least on this list, but it definitely seems that the sdmx-hd approach would be the way to go in terms of data exchange. The added complexity, at least if the local implementation team is already familiar with DHIS2, is of course to customise and maintain a totally new software package, but I would assume that a specialised software package for logistics management has lots of additional features that it probably will not make sense to include in DHIS2.

To come back to how the current DHIS2 version could support the requirements you listed (which I must say are very much like what I have seen in other countries), can I first ask that you share the paper form with us, it makes it so much easier to discuss the requirements.

Anyway, as with the requirements from Uganda, there are a few things that I see as problematic with the current data model in DHIS.

A) How to store in the database which items that where sent where and by whom.

E.g. when the national level sends drugs to the districts, or when districts sends to facilities, you write that they keep track of this information, like what (commodity +expiry date+quantity), to whom (orgunit), and when.

Keeping track of commodities over time and across levels is a bit outside the scope of the DHIS data model. While we can store how much is needed (the order), and how much was received, and using these also say something about the delivery status (delivered, not delivered, partially delivered), it is more tricky to store status on where each item is at a point in time, or where they were lost.

I guess we can create a double set of data elements so that the districts could register data per health facility (open each health facility in data entry) on what has been sent to that facility, and then later the health facility also registers (in another data set) what has actually been received. The data element name can be used to classify whether the commodity has been sent or received, e.g. the district will open a data set for a facility and only register data or the “sent” data elements,e.g. “Condom type A sent”, and then later the facility opens data entry and registers data (for the same month) for data elements like “Condom type A received”. Still we would be limited by a period type, I assume monthly, and registering the exact dates of when an item was sent and received (like a typical supply chain system), and then using these dates in reports etc. will be quite complex.

B) Dealing with periods and period types and tracking orders

At least in discussions about the requirements from Uganda this became a big issue, and it might be here as well. A drug distribution system for a big country does not always follow the calendar months, and e.g. in Uganda the have split the country into delivery zones and for each zone they have different start and end dates for the delivery cycles, so a 1 or 2 months cycle of delivery, use, new order does not follow the calendar months (Jan/Feb/Mar etc.) and hence are not periods of any DHIS period type, which makes data processing and reporting more complex.

If all the stock forms can follow calendar months it will be easier of course, but still only be a monthly reporting system with monthly status reports on stocks (orders, delivery status, stock-outs etc.). The status on where a drug shipment is at any point in time will be difficult to produce with today’s data model. The “sent” dataset which stores information on which drugs have been sent out will most likely need to have the same period type as the dataset with the stock balance and orders, which is monthly, and therefore are not that easy to use when you want to track a shipment or order (as in finding out at which orguinit it is at any point in time).

There are probably more issues as well and it would be great if we could systematically gathering requirements and start looking at what can be supported and not supported in the current DHIS2 and then look at what would be needed to move forward with a new module for this.

So coming back to how to do option 1), to simplify the requirements and use the current data model of DHIS2 I would say that the requirement to register that drugs have been sent out needs to go. If you can reduce the requirements to include monthly reports on what has been received, used, and what is needed for the next period, then I think DHIS2 can do it. Then you reduce the stock or delivery status to a monthly summary which shows which orders were completed, not completed and partially completed by comparing previous month’s order/requests with current month’s delivery/received items.

To add some kind of notification that an order has been received and processed it can be possible to add some additional properties or metadata to the form itself, or the dataset instances. You may have seen the “Complete” button at the bottom of the data entry form, and we could possibly add more options here, like “received by FHB (level 1)”, “sent from FHB” etc. which would then say something about the status for the complete order, and not for individual line items (data elements) in the order. These status fields about a form (dataset+orgunit+period) can say something about the status of the order at any point in time and are not bound by the limitation of the period type for the form. It will not be as accurate as tracing status of each drug item, but might be enough information anyway.

A few comments on categories, forms and reports from your discussions so far:

Data element categories to store stock data

A general rule for designing data elements and categories is to make sure that the sum of all the options in a category (and categorycombo) add up to a meaningful total. This way the total and subtotal values for a data element are also meaningful and can be used across the system when designing charts, reports, maps etc. See chapter 2 in user manual for more info on this.

However, with the stock forms and other forms of similar character (hundreds of rows and many columns) it seems very stupid to create data element for each “field” in the form, and not to use categories. You’ll end up with a very long list of data elements just for stock data, typically with more data elements that all the other health programs together, which makes the application slow to use and also makes it difficult to browse the data elements list looking for non-stock data. For this reason we have thought of a new feature, which is to specify in the categorycombo whether it should be aggregated up to a total or not, whether it is “aggregatable”. This will then allow us to filter away the data elements totals and subtotals that should not be generated since their catcombo is non-aggregatable. We haven’t decided on all the details yet, but the point is that it will be easier and better to use catcombos also when the columns in the form do not add up to a total, like in the typical stock forms.

Calculated fields in the data entry form, e.g. “quantity required next month”

Another related feature that we are planning is to allow for expressions in custom data entry forms. E.g. in the stock form many of the columns are calculations, like the end balance, the requested number of new items (the order), average monthly use etc. and these are not supported at the moment. The idea is to include the possibility of inserting expressions into fields in the custom for just like you can insert data element+catoptioncombo.

Custom reports for stock data

To comment on the reporting requirements from Sri Lanka, e.g. to list all orgunits that have received a specific drug that can be done using custom report designers like BIRT or IReport. There you will be able to produce most types of reports and using report tables with parameters as your data source you can make these quite dynamic. Currently we don’t have data element as report parameter for report tables, but I guess we can find a way to do that as well, so that you can get a report with e.g. a list of all orgunits at level= 3 where for data element=“Condom type A”, Catoptioncombo=“received”, Period= “Mar-2010”, and datavalue > 0.

Typically I would that it is easier to find a solution for the reporting requirements than a good solution for how to store the data, or without a smart way of storing the data the reporting will be very complex and difficult.

Would be good to start a wider discussion around these issues as these are quite general requirements that any country will put forward at some point. I don’t think that there is one solution to logistics management that will fit all countries that already use DHIS2, as e.g whether or not to maintain a separate software will depend on many local factors, and how advanced system that is needed also varies from country to country. What would be good is to continue this discussion on how and whether DHIS2 can support these more general requirements, and look at what steps we can take to improve the situation, both short term and long term.

···

Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736

Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link


Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 4 November 2010 09:04, Kim-Anh Vo catakim@gmail.com wrote:

hello,

On Thu, Nov 4, 2010 at 1:47 PM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Hi Kim Anh,
Thanks a lot for your ideas.
There are some things I am still don’t understand much. Could you please explain more detail about manage items. and how to create that in current DHIS. I still can’t image how to do it using dataelement and data entry form.

Example

I

  1. FHB receives items from supplier.
    They will input the details of items as below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 100 - 50000
Condom B - CB - 03/2014 - 150 - 10000

Condom C - CC - 09/2011 - 50 - 20000

currently, DHIS2 need more development for be able to apply this.
basically and actually DHIS2 design is not for drugs management.

But for adaptation, you can just see each cell in the table as a dael.

How much items there? For only contraception program… I guess it’s really not too much, right? 100?
(name-based module is working on this: attributes,… free to add more… but this is just for reference and still being developed/designed… its purpose-the module, I mean, is not for drugs also!)

  1. FHB view reports from RMDSs Report look like the 1158 form and see that RMDS1 need 1000 condoms. So FHB issues to RMDS1 1000 condoms (A, B, C)

thinking of separating request and return… 2 different data-flow… for easy management/monitoring later.
All RMDSs report (1158 form) —> FHB : request data-flow (equivalent to data-flow dataset, for example, just called: “1158-Request-DataElementSet”).

FHB issues (1158 form also) —> RMDS(s) : return data-flow (“1158-Return-DataElementSet”)

Actually, the later (return data-flow) is the core needed to monitor data-flow. The former (request data-flow) is for recorded/checked out later… For example, it only does COUNT if the FHB can afford to issue the numbers of items, not the numbers of items in the request (following my understanding through the project descriptions).

Possible data-entry form:

  1. For request: simple request daels
  2. For return: same form but showing both requested and returned/issued daels in the same cells, just add some texts to distinguish them. This help the officer at FHB to monitor the request info while replying/issuing.

(the already data-input for request form will be showed in this form if period is the same… I believe you know this too!)

  1. RMDS1 receives items from FHB and input details of items they got as below

Name - Code - Date exp - Unit Price - Quantity

Condom A - CA - 11/2012 - 110 - 300

Condom B - CB - 03/2014 - 160 - 200

Condom C - CC - 09/2011 - 60 - 500

the same drugs but why diff information at different level?
It’s not mentioned in the descriptions of the project, right?

  1. RMDS1 view reports 1158 from MOHs to see how much their MOHs want and see MOH11 need 500 comdoms this month. So RMDS1 issue 500 condoms (A, B, C) to the MOH1. (each RMDS has about 7 to 15 MOHs)

the same as point nr. 2
Dataset-report can be used in here!

  1. MOH11 receives items from RMDS1 and input details of items they got

Name - Code - Date exp - Unit Price - Quantity

Condom A - CA - 11/2012 - 120 - 100

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity

Condom C - CA - 11/2012 - 120 - 45

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity

Condom C - CC - 11/2012 - 120 - 30

Condom B - CB - 03/2014 - 160 - 50

Then my question is if we can use current DHIS, then how can we identify which one is data element?

Currently DHIS2, dael just consists of attributes: name, shortname, description, etc. in one OBJECT, dataelement.

If wanting to manage each of the attribute entities: code, date exp, etc… JUST break it DOWN … into dataelement
(as said in point nr. 1)

If we create Comdom A as a data element with categories options are Name, code, date exp, unit price, quantity is impossible. Because catgory options are same data type

This is a way.

If we create seperate data elements as Comdom A Name, Condom A code, Condom A Date Exp,… then there would be many data elements, and these data entry forms won’t be stable because when time change, there would be be new kind of condom D available in the market.

It depends on the choices… how many items(drugs) of the contraceptive stock programe?

What’s the point of number of daels and stability of data-entry form?
If having more items (like condom D as you gave out), user just create new daels for that item.

This is a good practice of DHIS2… and because DHIS2’s design is for that.
For categories, you couldn’t make changes. Moreover, category-concept is quite not fit in this case (non-sense for the total… you just exploit its by reducing daels defined).

And currently there is not Search function for data values in DHIS in aggregated report. So if I have the Condom name, I want to generate the list of organistation units were got it for last 6 months. but not view in each org unit. Because there would be many organisation units there.

simply… as we might did here in Vietnam before maybe, add an representative OU for all of them :wink:

I need more your explainations

These above are just my own understanding/analysis, anyone from HISP can help out more :slight_smile: with comments!

Thuy
---------- Forwarded message ----------
From: Kim-Anh Vo catakim@gmail.com

Date: Thu, Nov 4, 2010 at 10:31 AM
Subject: Re: New requirement from Sri Lanka

To: Thuy Nguyen thuy.hispvietnam@gmail.com

hello again,

That’s really interesting… as I guess.

DHIS2 is possible to be customized for monitoring items through levels.

Data:
There are two data-flow to be kept in mind: upward (request) and downward (return).

They’re all the input-data indeed!
So we need 2 collection of daels (categories also) with request/return as the identifiers.

Services: all functions taken place by calculation/modification/… between these two data-flow. Eg: reports (aggregated input data - the same form for input data up/downward and output, and monitoring purpose as well), analysis by chart, GIS.

With BIRT + reporttable concept (DHIS2): almost report-issues have clues for solution.

Keep it as simple as possible :slight_smile:

Let me know how he project is going in the future.
I’m interested the practical uses/customizations of DHIS2 like this!

On Thu, Nov 4, 2010 at 10:27 AM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

---------- Forwarded message ----------
From: Thuy Nguyen thuy.hispvietnam@gmail.com

Date: Tue, Nov 2, 2010 at 3:44 AM
Subject: Re: New requirement from Sri Lanka
To: John lewis johnlewis.hisp@gmail.com

I was sleeping but wake up in the night and can’t stop thinking of the project. Let me describ more about the process of existing system. There was an activity diagram but the doc she sent me by docx, i can’t see any table in that. I will send you tomorrow.

Level 1 National : FHB

Level 2 District : RMSD

Level 3 Division : MOH

The process from bottom to top

  1. the MOH send the request form to RMSD. The form has code RH MIS 1158 (Monthly Contraceptive Strock Return/Request form) as I sent in previous email.First of all
  • This form has information of
  • Month - Year send request
  • Places the form would be sent to
  • The main area of the form has a table with
  • row is : condom, oral pill packet, injectables (DBMA) vials, intra uterine device and implants
  • column is :
  1. Amount remain at the end of last month (a),
  2. amount received during a month,
  3. total
  4. amount issued/despensed during the month,
  5. amount remain at the end of the month
  6. amount require
  7. average monthly requirement :
  8. min qty
  9. max qty: depend on the need of that stock.
    (3) = (1)+(2)

(4)
(5) = (3)-(4)
(5) → (1) in next month
(6)=(8)-(5)
(7)= (sum (4) ) / Xmonths
(8)= Y * (7)
(9) = Z * (7)

X : is number of months ( but atleast 3 months, or 6 months, 12 months,…)
Y : is minimum months of stock (Mos) that the specified org unit need to store. Example the min of MOH is 2 months of store. So if the (7) is 150. then Min quantity of MOH is 150 *2

Z : is maximum months of stock.

  1. RMSD has 3 things to do
  • look at the form with the number of items required from MOH, and depend on min max qty and the quantity where RDHS stock has ,they issue items to MOH. They also track information of items they issued to which MOH
  • send the RH MIS 1158 to FHB to report remain items, issued items and require number of new items. (same with MOH send request form to it)
  • After received items from FHB, RDHS need to confirm FHB that they got the items.
  1. FHB has 3 things to do
  • receive the request form and issue items from RMSD.
  • If the stock has not enough item, or need more, then it will get the items from suppliers.
  • FHB also have detail information of items they got from supplier (name, quantity, date expiry, batch number, unit price, quantity price)
  • FHB issue items to RMSD. information of issue (Issue date, item names, quantity, date expiry, batch/lot number, unit price, quantity price, distribute to) it can be refered from “Out put item report.JPG” file.

They want all information is save in central database, so that they can get all kind of report, and if there is problem with item, then they can generate report contain org unit were issued.

Anyway, I will work with her every afternoon so I will discuss more and get more information.


Thuy


Thuy

Best regards,
Kim-Anh Vo

Best regards,
Kim-Anh Vo


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Hi Ola,

Thank you very much for your mail. According to what you explained about Uganda’s system. I think that it’s almost same with Sri Lanka’s one.

I attaching the documentations of the system to you so that you can easy understand it.

I will read your email again to understand more.

LogicsticManagementSystem.zip (436 KB)

···


Thuy

A few quick thoughts. Agree this requirement for inventory/stock
control seems to be everywhere. Maybe worth noting that the hospital
system which HISP India are basing on openmrs also has a requirement
for inventory/stock/pharmacy and someone is working on an openmrs
module for this. Might be good to harmonize efforts there but perhaps
it will be difficult. The emphasis there is on managing stores at
facility level.

Hi,
Thanks to Thuy for sharing this discussion (see below my email) with all of
us on the list.
Over the last month or so we've had many requests regarding logistics
management or supply chain systems like the one you are describing from Sri
Lanka Thuy. It is a burning hot issue it seems and it is good to have some
discussions around it and to think collectively on how we can support this
in the context of a DHIS implementation.
I commented on this in a recent discussion about similar requirements from
Uganda, and I sort of ended up with proposing 3 alternatives to them:
1) Simplify the requirements and implement it in the current version of
DHIS2
2) Build a new module for basic logistics management in DHIS2
3) Use an external software solution specialised for logistics management
(e.g. the open source alternative OpenLMIS) and make sure you integrate this
with DHIS2 both in terms of data exchange and facilitating easy
co-installations of both systems.
My advice would be to start with 1), and show what the current DHIS2 can do,
and then in parallel start thinking of a more long term solution, 2) or 3).
I think given all the interest in implementing basic logistics management in
relation to DHIS2 implementations it might be worth investigating what 2)
means in terms of what the requirements are and how much work it would be to
do this inside DHIS2.
3) is of course a little outside our scope, at least on this list, but
it definitely seems that the sdmx-hd approach would be the way to go in
terms of data exchange. The added complexity, at least if the local
implementation team is already familiar with DHIS2, is of course to
customise and maintain a totally new software package, but I would assume
that a specialised software package for logistics management has lots of
additional features that it probably will not make sense to include in
DHIS2.
To come back to how the current DHIS2 version could support the requirements
you listed (which I must say are very much like what I have seen in other
countries), can I first ask that you share the paper form with us, it makes
it so much easier to discuss the requirements.
Anyway, as with the requirements from Uganda, there are a few things that I
see as problematic with the current data model in DHIS.
A) How to store in the database which items that where sent where and by
whom.
E.g. when the national level sends drugs to the districts, or when districts
sends to facilities, you write that they keep track of this information,
like what (commodity +expiry date+quantity), to whom (orgunit), and when.
Keeping track of commodities over time and across levels is a bit outside
the scope of the DHIS data model. While we can store how much is needed (the
order), and how much was received, and using these also say something about
the delivery status (delivered, not delivered, partially delivered), it is
more tricky to store status on where each item is at a point in time, or
where they were lost.
I guess we can create a double set of data elements so that the districts
could register data per health facility (open each health facility in data
entry) on what has been sent to that facility, and then later the health
facility also registers (in another data set) what has actually been
received. The data element name can be used to classify whether the
commodity has been sent or received, e.g. the district will open a data set
for a facility and only register data or the "sent" data elements,e.g.
"Condom type A sent", and then later the facility opens data entry and
registers data (for the same month) for data elements like "Condom type A
received". Still we would be limited by a period type, I assume monthly, and
registering the exact dates of when an item was sent and received (like a
typical supply chain system), and then using these dates in reports etc.
will be quite complex.
B) Dealing with periods and period types and tracking orders
At least in discussions about the requirements from Uganda this became a big
issue, and it might be here as well. A drug distribution system for a big
country does not always follow the calendar months, and e.g. in Uganda the
have split the country into delivery zones and for each zone they have
different start and end dates for the delivery cycles, so a 1 or 2 months
cycle of delivery, use, new order does not follow the calendar months
(Jan/Feb/Mar etc.) and hence are not periods of any DHIS period type, which
makes data processing and reporting more complex.
If all the stock forms can follow calendar months it will be easier of
course, but still only be a monthly reporting system with monthly status
reports on stocks (orders, delivery status, stock-outs etc.). The status on
where a drug shipment is at any point in time will be difficult to produce
with today's data model. The "sent" dataset which stores information on
which drugs have been sent out will most likely need to have the same period
type as the dataset with the stock balance and orders, which is monthly, and
therefore are not that easy to use when you want to track a shipment or
order (as in finding out at which orguinit it is at any point in time).

There are probably more issues as well and it would be great if we could
systematically gathering requirements and start looking at what can be
supported and not supported in the current DHIS2 and then look at what would
be needed to move forward with a new module for this.
So coming back to how to do option 1), to simplify the requirements and use
the current data model of DHIS2 I would say that the requirement to register
that drugs have been sent out needs to go. If you can reduce the
requirements to include monthly reports on what has been received, used, and
what is needed for the next period, then I think DHIS2 can do it. Then you
reduce the stock or delivery status to a monthly summary which shows which
orders were completed, not completed and partially completed by comparing
previous month's order/requests with current month's delivery/received
items.
To add some kind of notification that an order has been received and
processed it can be possible to add some additional properties or metadata
to the form itself, or the dataset instances. You may have seen the
"Complete" button at the bottom of the data entry form, and we could
possibly add more options here, like "received by FHB (level 1)", "sent from
FHB" etc. which would then say something about the status for the complete
order, and not for individual line items (data elements) in the order. These
status fields about a form (dataset+orgunit+period) can say something about
the status of the order at any point in time and are not bound by the
limitation of the period type for the form. It will not be as accurate as
tracing status of each drug item, but might be enough information anyway.

A few comments on categories, forms and reports from your discussions so
far:
Data element categories to store stock data
A general rule for designing data elements and categories is to make sure
that the sum of all the options in a category (and categorycombo) add up to
a meaningful total. This way the total and subtotal values for a data
element are also meaningful and can be used across the system when designing
charts, reports, maps etc. See chapter 2 in user manual for more info on
this.
However, with the stock forms and other forms of similar character (hundreds
of rows and many columns) it seems very stupid to create data element for
each "field" in the form, and not to use categories. You'll end up with a
very long list of data elements just for stock data, typically with more
data elements that all the other health programs together, which makes theCould
application slow to use and also makes it difficult to browse the data
elements list looking for non-stock data. For this reason we have thought of
a new feature, which is to specify in the categorycombo whether it should be
aggregated up to a total or not, whether it is "aggregatable". This will
then allow us to filter away the data elements totals and subtotals that
should not be generated since their catcombo is non-aggregatable. We haven't
decided on all the details yet, but the point is that it will be easier and
better to use catcombos also when the columns in the form do not add up to a
total, like in the typical stock forms.
Calculated fields in the data entry form, e.g. "quantity required next
month"
Another related feature that we are planning is to allow for expressions in
custom data entry forms. E.g. in the stock form many of the columns are
calculations, like the end balance, the requested number of new items (the
order), average monthly use etc. and these are not supported at the moment.
The idea is to include the possibility of inserting expressions into fields
in the custom for just like you can insert data element+catoptioncombo.

Who is "we" in the above? I am not sure I agree with the new feature
proposal re aggregatable vs non aggregatable categories (catcombo is
not relevant - I guess we are talking about categories). Would have
to think more of the consequences but not now.

Expressions in forms sounds good.

- Bob

···

On 4 November 2010 10:53, Ola Hodne Titlestad <olati@ifi.uio.no> wrote:

Custom reports for stock data
To comment on the reporting requirements from Sri Lanka, e.g. to list all
orgunits that have received a specific drug that can be done using custom
report designers like BIRT or IReport. There you will be able to produce
most types of reports and using report tables with parameters as your data
source you can make these quite dynamic. Currently we don't have data
element as report parameter for report tables, but I guess we can find a way
to do that as well, so that you can get a report with e.g. a list of all
orgunits at level= 3 where for data element="Condom type A",
Catoptioncombo="received", Period= "Mar-2010", and datavalue > 0.
Typically I would that it is easier to find a solution for the reporting
requirements than a good solution for how to store the data, or without a
smart way of storing the data the reporting will be very complex and
difficult.
Would be good to start a wider discussion around these issues as these are
quite general requirements that any country will put forward at some point.
I don't think that there is one solution to logistics management that will
fit all countries that already use DHIS2, as e.g whether or not to maintain
a separate software will depend on many local factors, and how advanced
system that is needed also varies from country to country. What would be
good is to continue this discussion on how and whether DHIS2 can support
these more general requirements, and look at what steps we can take to
improve the situation, both short term and long term.

----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link
----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 4 November 2010 09:04, Kim-Anh Vo <catakim@gmail.com> wrote:

hello,

On Thu, Nov 4, 2010 at 1:47 PM, Thuy Nguyen <thuy.hispvietnam@gmail.com> >> wrote:

Hi Kim Anh,
Thanks a lot for your ideas.
There are some things I am still don't understand much. Could you please
explain more detail about manage items. and how to create that in current
DHIS. I still can't image how to do it using dataelement and data entry
form.

Example

I
1. FHB receives items from supplier.
They will input the details of items as below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 100 - 50000
Condom B - CB - 03/2014 - 150 - 10000
Condom C - CC - 09/2011 - 50 - 20000

currently, DHIS2 need more development for be able to apply this.
basically and actually DHIS2 design is not for drugs management.

But for adaptation, you can just see each cell in the table as a dael.
How much items there? For only contraception program... I guess it's
really not too much, right? 100?
(name-based module is working on this: attributes,... free to add more....
but this is just for reference and still being developed/designed... its
purpose-the module, I mean, is not for drugs also!)

2. FHB view reports from RMDSs Report look like the 1158 form and see
that RMDS1 need 1000 condoms. So FHB issues to RMDS1 1000 condoms (A, B, C)

thinking of separating request and return.... 2 different data-flow... for
easy management/monitoring later.
All RMDSs report (1158 form) ---> FHB : request data-flow (equivalent to
data-flow dataset, for example, just called: "1158-Request-DataElementSet").
FHB issues (1158 form also) ---> RMDS(s) : return data-flow
("1158-Return-DataElementSet")

Actually, the later (return data-flow) is the core needed to monitor
data-flow. The former (request data-flow) is for recorded/checked out
later.... For example, it only does COUNT if the FHB can afford to issue the
numbers of items, not the numbers of items in the request (following my
understanding through the project descriptions).

Possible data-entry form:
1. For request: simple request daels
2. For return: same form but showing both requested and returned/issued
daels in the same cells, just add some texts to distinguish them. This help
the officer at FHB to monitor the request info while replying/issuing.
(the already data-input for request form will be showed in this form if
period is the same... I believe you know this too!)

3. RMDS1 receives items from FHB and input details of items they got as
below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 110 - 300
Condom B - CB - 03/2014 - 160 - 200
Condom C - CC - 09/2011 - 60 - 500

the same drugs but why diff information at different level?
It's not mentioned in the descriptions of the project, right?

4. RMDS1 view reports 1158 from MOHs to see how much their MOHs want and
see MOH11 need 500 comdoms this month. So RMDS1 issue 500 condoms (A, B, C)
to the MOH1. (each RMDS has about 7 to 15 MOHs)

the same as point nr. 2
Dataset-report can be used in here!

5. MOH11 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 120 - 100

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom C - CA - 11/2012 - 120 - 45

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom C - CC - 11/2012 - 120 - 30
Condom B - CB - 03/2014 - 160 - 50

Then my question is if we can use current DHIS, then how can we identify
which one is data element?

Currently DHIS2, dael just consists of attributes: name, shortname,
description, etc. in one OBJECT, dataelement.
If wanting to manage each of the attribute entities: code, date exp,
etc.... JUST break it DOWN ... into dataelement
(as said in point nr. 1)

If we create Comdom A as a data element with categories options are Name,
code, date exp, unit price, quantity is impossible. Because catgory options
are same data type

This is a way.

If we create seperate data elements as Comdom A Name, Condom A code,
Condom A Date Exp,.. then there would be many data elements, and these data
entry forms won't be stable because when time change, there would be be new
kind of condom D available in the market.

It depends on the choices... how many items(drugs) of the contraceptive
stock programe?

What's the point of number of daels and stability of data-entry form?
If having more items (like condom D as you gave out), user just create new
daels for that item.
This is a good practice of DHIS2... and because DHIS2's design is for
that.
For categories, you couldn't make changes. Moreover, category-concept is
quite not fit in this case (non-sense for the total... you just exploit its
by reducing daels defined).

And currently there is not Search function for data values in DHIS in
aggregated report. So if I have the Condom name, I want to generate the list
of organistation units were got it for last 6 months. but not view in each
org unit. Because there would be many organisation units there.

simply... as we might did here in Vietnam before maybe, add an
representative OU for all of them :wink:

I need more your explainations

These above are just my own understanding/analysis, anyone from HISP can
help out more :slight_smile: with comments!

Thuy
---------- Forwarded message ----------
From: Kim-Anh Vo <catakim@gmail.com>
Date: Thu, Nov 4, 2010 at 10:31 AM
Subject: Re: New requirement from Sri Lanka
To: Thuy Nguyen <thuy.hispvietnam@gmail.com>

hello again,

That's really interesting... as I guess.
DHIS2 is possible to be customized for monitoring items through levels.

Data:
There are two data-flow to be kept in mind: upward (request) and downward
(return).
They're all the input-data indeed!
So we need 2 collection of daels (categories also) with request/return as
the identifiers.

Services: all functions taken place by calculation/modification/...
between these two data-flow. Eg: reports (aggregated input data - the same
form for input data up/downward and output, and monitoring purpose as well),
analysis by chart, GIS.
With BIRT + reporttable concept (DHIS2): almost report-issues have clues
for solution.

Keep it as simple as possible :slight_smile:

Let me know how he project is going in the future.
I'm interested the practical uses/customizations of DHIS2 like this!

On Thu, Nov 4, 2010 at 10:27 AM, Thuy Nguyen <thuy.hispvietnam@gmail.com> >>> wrote:

---------- Forwarded message ----------
From: Thuy Nguyen <thuy.hispvietnam@gmail.com>
Date: Tue, Nov 2, 2010 at 3:44 AM
Subject: Re: New requirement from Sri Lanka
To: John lewis <johnlewis.hisp@gmail.com>

I was sleeping but wake up in the night and can't stop thinking of the
project. Let me describ more about the process of existing system. There was
an activity diagram but the doc she sent me by docx, i can't see any table
in that. I will send you tomorrow.

Level 1 National : FHB

Level 2 District : RMSD

Level 3 Division : MOH

The process from bottom to top

1. the MOH send the request form to RMSD. The form has code RH MIS 1158
(Monthly Contraceptive Strock Return/Request form) as I sent in previous
email.First of all

This form has information of

Month - Year send request
Places the form would be sent to
The main area of the form has a table with

row is : condom, oral pill packet, injectables (DBMA) vials, intra
uterine device and implants
column is :

Amount remain at the end of last month (a),
amount received during a month,
total
amount issued/despensed during the month,
amount remain at the end of the month
amount require
average monthly requirement :
min qty
max qty: depend on the need of that stock.

(3) = (1)+(2)
(4)
(5) = (3)-(4)
(5) -> (1) in next month
(6)=(8)-(5)
(7)= (sum (4) ) / Xmonths
(8)= Y * (7)
(9) = Z * (7)

X : is number of months ( but atleast 3 months, or 6 months, 12
months,...)
Y : is minimum months of stock (Mos) that the specified org unit need to
store. Example the min of MOH is 2 months of store. So if the (7) is 150.
then Min quantity of MOH is 150 *2
Z : is maximum months of stock.

2. RMSD has 3 things to do

look at the form with the number of items required from MOH, and depend
on min max qty and the quantity where RDHS stock has ,they issue items to
MOH. They also track information of items they issued to which MOH
send the RH MIS 1158 to FHB to report remain items, issued items and
require number of new items. (same with MOH send request form to it)
After received items from FHB, RDHS need to confirm FHB that they got
the items.

3. FHB has 3 things to do

receive the request form and issue items from RMSD.
If the stock has not enough item, or need more, then it will get the
items from suppliers.
FHB also have detail information of items they got from supplier (name,
quantity, date expiry, batch number, unit price, quantity price)
FHB issue items to RMSD. information of issue (Issue date, item names,
quantity, date expiry, batch/lot number, unit price, quantity price,
distribute to) it can be refered from "Out put item report.JPG" file.

They want all information is save in central database, so that they can
get all kind of report, and if there is problem with item, then they can
generate report contain org unit were issued.

Anyway, I will work with her every afternoon so I will discuss more and
get more information.

--
Thuy

--
Thuy

--
--
Best regards,
Kim-Anh Vo

--
--
Best regards,
Kim-Anh Vo

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

Hi all

yes, this requirement is popping up everywhere, and we seem to be talking
about two different systems:

1) Inventory: what is available, where? stock-outs, waste rates etc
2) Logistics: procuring and distributing. Follow-up and paying

For the first, it has been quite common to use something that would work
well in DHIS2, like a table of commodities with some aggregate data like
balance, waste, used. But as Ola points out, there is a tendency that the
forms for this are extremely big, and try to function also as a surrogate
for number 2) above. If going for an inventory-solution, there are a few
useful indicators for managing the logistics, such as stock-out rates and
waste-rates, which can function quite well in adjusting the distribution
from central stores.

For a "proper" logistics system, we have all the data types and
functionalities that is typically not supported by DHIS2. Ordering,
manually or automatically, when stocks run low, following the order in the
distribution chain, and acknowledge receipt etc. An additional reuirement,
especially to combat corruption, can be to manage central stores with
bar-code systems, much like DHL or some other logistics service provider
are doing. Payment of procurements can also be envisioned as a
requirement. This is of course more tricky, but there are a few solutions
out there that at least are one their way towards this.

Like Ola said, I think going for a trimmed-down inventory solution is a
good place to start, but we should also keep track of all
requests/requirements for a logistics system, and hopefully we can start
collaborating with someone like VillageReach in Sierra Leone quite soon.

Johan

···

A few quick thoughts. Agree this requirement for inventory/stock
control seems to be everywhere. Maybe worth noting that the hospital
system which HISP India are basing on openmrs also has a requirement
for inventory/stock/pharmacy and someone is working on an openmrs
module for this. Might be good to harmonize efforts there but perhaps
it will be difficult. The emphasis there is on managing stores at
facility level.

On 4 November 2010 10:53, Ola Hodne Titlestad <olati@ifi.uio.no> wrote:

Hi,
Thanks to Thuy for sharing this discussion�(see below my email)�with all
of
us on the list.
Over the last month or so we've had many requests regarding logistics
management or supply chain systems like the one you are describing from
Sri
Lanka Thuy. It is a burning hot issue it seems and it is good to have
some
discussions around it and to think collectively on how we can support
this
in the context of a DHIS implementation.
I commented on this in a recent discussion about similar requirements
from
Uganda, and I sort of ended up with proposing 3 alternatives to them:
1) Simplify the requirements and implement it in the current version of
DHIS2
2) Build a new module for basic logistics management in DHIS2
3) Use an external software solution specialised for logistics
management
(e.g. the open source alternative OpenLMIS) and make sure you integrate
this
with DHIS2 both in terms of data exchange and facilitating easy
co-installations of both systems.
My advice would be to start with 1), and show what the current DHIS2 can
do,
and then in�parallel�start thinking of a more long term solution, 2) or
3).
I think given all the interest in implementing basic logistics
management in
relation to DHIS2 implementations it might be worth investigating what
2)
means in terms of what the requirements are and how much work it would
be to
do this inside DHIS2.
3) is of course a little outside our scope, at least on this list, but
it�definitely�seems that the sdmx-hd approach would be the way to go in
terms of data exchange. The added complexity, at least if the local
implementation team is already familiar with DHIS2, is of course to
customise and maintain a totally new software package, but I would
assume
that a specialised software package for logistics management has lots of
additional features that it probably will not make sense to include in
DHIS2.
To come back to how the current DHIS2 version could support the
requirements
you listed (which I must say are very much like what I have seen in
other
countries), can I first ask that you share the paper form with us, it
makes
it so much easier to discuss the requirements.
Anyway, as with the requirements from Uganda, there are a few things
that I
see as problematic with the current data model in DHIS.
A) How to store in the database which items that where sent where and by
whom.
E.g. when the national level sends drugs to the districts, or when
districts
sends to facilities, you write that they keep track of this information,
like what (commodity +expiry date+quantity), to whom (orgunit), and
when.
Keeping track of commodities over time and across levels is a bit
outside
the scope of the DHIS data model. While we can store how much is needed
(the
order), and how much was received, and using these also say something
about
the delivery status (delivered, not delivered, partially delivered), it
is
more tricky to store status on where each item is at a point in time, or
where they were lost.
I guess we can create a double set of data elements so that the
districts
could register data per health facility (open each health facility in
data
entry) on what has been sent to that facility, and then later the health
facility also registers (in another data set) what has actually been
received. The data element name can be used to classify whether the
commodity has been sent or received, e.g. the district will open a data
set
for a facility and only register data or the "sent" data elements,e.g.
"Condom type A sent", and then later the facility opens data entry and
registers data (for the same month) for data elements like "Condom type
A
received".�Still we would be limited by a period type, I assume monthly,
and
registering the exact dates of when an item was sent and received (like
a
typical supply chain system), and then using these dates in reports etc.
will be quite complex.
B) Dealing with periods and period types and tracking orders
At least in discussions about the requirements from Uganda this became a
big
issue, and it might be here as well. A drug distribution system for a
big
country does not always follow the calendar months, and e.g. in Uganda
the
have split the country into delivery zones and for each zone they have
different start and end dates for the delivery cycles, so a 1 or 2
months
cycle of delivery, use, new order does not follow the calendar months
(Jan/Feb/Mar etc.) and hence are not periods of any DHIS period type,
which
makes data processing and reporting more complex.
If all the stock forms can follow calendar months it will be easier of
course, but still only be a monthly reporting system with monthly status
reports on stocks (orders, delivery status, stock-outs etc.). The status
on
where a drug shipment is at any point in time will be difficult to
produce
with today's data model. The "sent" dataset which stores information on
which drugs have been sent out will most likely need to have the same
period
type as the dataset with the stock balance and orders, which is monthly,
and
therefore are not that easy to use when you want to track a shipment or
order (as in finding out at which orguinit it is at any point in time).

There are probably more issues as well and it would be great if we could
systematically �gathering requirements and start looking at what can be
supported and not supported in the current DHIS2 and then look at what
would
be needed to move forward with a new module for this.
So coming back to how to do option 1), to simplify the requirements and
use
the current data model of DHIS2 I would say that the requirement to
register
that drugs have been sent out needs to go. If you can reduce the
requirements to include monthly reports on what has been received, used,
and
what is needed for the next period, then I think DHIS2 can do it. Then
you
reduce the stock or delivery status to a monthly summary which shows
which
orders were completed, not completed and partially completed by
comparing
previous month's order/requests with current month's delivery/received
items.
To add some kind of notification that an order has been received and
processed it can be possible to add some additional properties or
metadata
to the form itself, or the dataset instances. �You may have seen the
"Complete" button at the bottom of the data entry form, and we could
possibly add more options here, like "received by FHB (level 1)", "sent
from
FHB" etc. which would then say something about the status for the
complete
order, and not for individual line items (data elements) in the order.
These
status fields about a form (dataset+orgunit+period) can say something
about
the status of the order at any point in time and are not bound by the
limitation of the period type for the form. It will not be as accurate
as
tracing status of each drug item, but might be enough information
anyway.

A few comments on categories, forms and reports from your discussions so
far:
Data element categories to store stock data
A general rule for designing data elements and categories is to make
sure
that the sum of all the options in a category (and categorycombo) add up
to
a meaningful total.�This way the total and subtotal values for a data
element are also meaningful and can be used across the system when
designing
charts, reports, maps etc. See chapter 2 in user manual for more info on
this.
However, with the stock forms and other forms of similar character
(hundreds
of rows and many columns) it seems very stupid to create data element
for
each "field" in the form, and not to use categories. You'll end up with
a
very long list of data elements just for stock data, typically with more
data elements that all the other health programs together, which makes
theCould
application slow to use and also makes it difficult to browse the data
elements list looking for non-stock data. For this reason we have
thought of
a new feature, which is to specify in the categorycombo whether it
should be
aggregated up to a total or not, whether it is "aggregatable". This will
then allow us to filter away the data elements totals and subtotals that
should not be generated since their catcombo is non-aggregatable. We
haven't
decided on all the details yet, but the point is that it will be easier
and
better to use catcombos also when the columns in the form do not add up
to a
total, like in the typical stock forms.
Calculated fields in the data entry form, e.g. "quantity required next
month"
Another related feature that we are planning is to allow for expressions
in
custom data entry forms. E.g. in the stock form many of the columns are
calculations, like the end balance, the requested number of new items
(the
order), average monthly use etc. and these are not supported at the
moment.
The idea is to include the possibility of inserting expressions into
fields
in the custom for just like you can insert data element+catoptioncombo.

Who is "we" in the above? I am not sure I agree with the new feature
proposal re aggregatable vs non aggregatable categories (catcombo is
not relevant - I guess we are talking about categories). Would have
to think more of the consequences but not now.

Expressions in forms sounds good.

- Bob

Custom reports for stock data
To comment on the reporting requirements from Sri Lanka, e.g. to list
all
orgunits that have received a specific drug that can be done using
custom
report designers like BIRT or IReport. There you will be able to produce
most types of reports and using report tables with parameters as your
data
source you can make these quite dynamic. Currently we don't have data
element as report parameter for report tables, but I guess we can find a
way
to do that as well, so that you can get a report with e.g. a list of all
orgunits at level= 3 where for data element="Condom type A",
Catoptioncombo="received", Period= "Mar-2010", and datavalue > 0.
Typically I would that it is easier to find a solution for the reporting
requirements than a good solution for how to store the data, or without
a
smart way of storing the data the reporting will be very complex and
difficult.
Would be good to start a wider discussion around these issues as these
are
quite general�requirements�that any country will put forward at some
point.
I don't think that there is one solution to logistics management that
will
fit all countries that already use DHIS2, as e.g whether or not to
maintain
a separate software will depend on many local factors, and how advanced
system that is needed also varies from country to country. What would be
good is to continue this discussion on how and whether DHIS2 can support
these more general requirements, and look at what steps we can take to
improve the situation, both short term and long term.

----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway.�Googlemaps link
----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 4 November 2010 09:04, Kim-Anh Vo <catakim@gmail.com> wrote:

hello,

On Thu, Nov 4, 2010 at 1:47 PM, Thuy Nguyen >>> <thuy.hispvietnam@gmail.com> >>> wrote:

Hi Kim Anh,
Thanks a lot for your ideas.
There are some things I am still don't understand much. Could you
please
explain more detail about manage items. and� how to create that in
current
DHIS. I still can't image how to do it using dataelement and data
entry
form.

Example

I
1. FHB receives items from supplier.
They will input the details of items as below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 100 - 50000
Condom B - CB - 03/2014 - 150 - 10000
Condom C - CC - 09/2011 - 50 - 20000

currently, DHIS2 need more development for be able to apply this.
basically and actually DHIS2 design is not for drugs management.

But for adaptation, you can just see each cell in the table as a dael.
How much items there? For only contraception program... I guess it's
really not too much, right? 100?
(name-based module is working on this: attributes,... free to add
more....
but this is just for reference and still being developed/designed...
its
purpose-the module, I mean, is not for drugs also!)

2. FHB view reports from RMDSs Report look like the 1158 form and see
that RMDS1 need 1000 condoms. So FHB issues to RMDS1 1000 condoms (A,
B, C)

thinking of separating request and return.... 2 different data-flow...
for
easy management/monitoring later.
All RMDSs report (1158 form) ---> FHB : request data-flow (equivalent
to
data-flow dataset, for example, just called:
"1158-Request-DataElementSet").
FHB issues (1158 form also) ---> RMDS(s) : return data-flow
("1158-Return-DataElementSet")

Actually, the later (return data-flow)� is the core needed to monitor
data-flow. The former (request data-flow) is for recorded/checked out
later.... For example, it only does COUNT if the FHB can afford to
issue the
numbers of items, not the numbers of items in the request (following my
understanding through the project descriptions).

Possible data-entry form:
1. For request: simple request daels
2. For return: same form but showing both requested and returned/issued
daels in the same cells, just add some texts to distinguish them. This
help
the officer at FHB to monitor the request info while replying/issuing.
(the already data-input for request form will be showed in this form if
period is the same... I believe you know this too!)

3. RMDS1 receives items from FHB and input details of items they got
as
below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 110 - 300
Condom B - CB - 03/2014 - 160 - 200
Condom C - CC - 09/2011 - 60 - 500

the same drugs but why diff information at different level?
It's not mentioned in the descriptions of the project, right?

4. RMDS1 view reports 1158 from MOHs to see how much their MOHs want
and
see MOH11 need 500 comdoms this month. So RMDS1 issue 500 condoms (A,
B, C)
to the MOH1. (each RMDS has about 7 to 15 MOHs)

the same as point nr. 2
Dataset-report can be used in here!

5. MOH11 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 120 - 100

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom C - CA - 11/2012 - 120 - 45

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom C - CC - 11/2012 - 120 - 30
Condom B - CB - 03/2014 - 160 - 50

Then my question is if we can use current DHIS, then how can we
identify
which one is data element?

Currently DHIS2, dael just consists of attributes: name, shortname,
description, etc. in one OBJECT, dataelement.
If wanting to manage each of the attribute entities: code, date exp,
etc.... JUST break it DOWN ... into dataelement
�(as said in point nr. 1)

If we create Comdom A as a data element with categories options are
Name,
code, date exp, unit price, quantity is impossible. Because catgory
options
are same data type

This is a way.

If we create seperate data elements as Comdom A Name, Condom A code,
Condom A Date Exp,.. then there would be many data elements, and these
data
entry forms won't be stable because when time change, there would be
be new
kind of condom D available in the market.

It depends on the choices... how many items(drugs) of the contraceptive
stock programe?

What's the point of number of daels and stability of data-entry form?
If having more items (like condom D as you gave out), user just create
new
daels for that item.
This is a good practice of DHIS2... and because DHIS2's design is for
that.
For categories, you couldn't make changes. Moreover, category-concept
is
quite not fit in this case (non-sense for the total... you just exploit
its
by reducing daels defined).

And currently there is not Search function for data values in DHIS in
aggregated report. So if I have the Condom name, I want to generate
the list
of organistation units were got it for last 6 months. but not view in
each
org unit. Because there would be many organisation units there.

simply... as we might did here in Vietnam before maybe, add an
representative OU for all of them :wink:

I need more your explainations

These above are just my own understanding/analysis, anyone from HISP
can
help out more :slight_smile: with comments!

Thuy
---------- Forwarded message ----------
From: Kim-Anh Vo <catakim@gmail.com>
Date: Thu, Nov 4, 2010 at 10:31 AM
Subject: Re: New requirement from Sri Lanka
To: Thuy Nguyen <thuy.hispvietnam@gmail.com>

hello again,

That's really interesting... as I guess.
DHIS2 is possible to be customized for monitoring items through
levels.

Data:
There are two data-flow to be kept in mind: upward (request) and
downward
(return).
They're all the input-data indeed!
So we need 2 collection of daels (categories also) with request/return
as
the identifiers.

Services: all functions taken place by calculation/modification/...
between these two data-flow. Eg: reports (aggregated input data - the
same
form for input data up/downward and output, and monitoring purpose as
well),
analysis by chart, GIS.
With BIRT + reporttable concept (DHIS2): almost report-issues have
clues
for solution.

Keep it as simple as possible :slight_smile:

Let me know how he project is going in the future.
I'm interested the practical uses/customizations of DHIS2 like this!

On Thu, Nov 4, 2010 at 10:27 AM, Thuy Nguyen >>>> <thuy.hispvietnam@gmail.com> >>>> wrote:

---------- Forwarded message ----------
From: Thuy Nguyen <thuy.hispvietnam@gmail.com>
Date: Tue, Nov 2, 2010 at 3:44 AM
Subject: Re: New requirement from Sri Lanka
To: John lewis <johnlewis.hisp@gmail.com>

I was sleeping but wake up in the night and can't stop thinking of
the
project. Let me describ more about the process of existing system.
There was
an activity diagram but the doc she sent me by docx, i can't see any
table
in that. I will send you tomorrow.

Level 1 National : FHB

Level 2 District : RMSD

Level 3 Division : MOH

The process from bottom to top

1. the MOH send the request form to RMSD. The form has code RH MIS
1158
(Monthly Contraceptive Strock Return/Request form) as I sent in
previous
email.First of all

This form has information of

Month - Year send request
Places the form would be sent to
The main area of the form has a table with

row is : condom, oral pill packet, injectables (DBMA) vials, intra
uterine device and implants
column is :

Amount remain at the end of last month (a),
�amount received during a month,
total
amount issued/despensed during the month,
amount remain at the end of the month
amount require
average monthly requirement :
min qty
max qty: depend on the need of that stock.

(3) = (1)+(2)
(4)
(5) = (3)-(4)
(5) -> (1) in next month
(6)=(8)-(5)
(7)= (sum (4) ) / Xmonths
(8)= Y * (7)
(9) = Z * (7)

X : is number of months ( but atleast 3 months, or 6 months, 12
months,...)
Y : is minimum months of stock (Mos) that the specified org unit need
to
store. Example the min of MOH is 2 months of store. So if the (7) is
150.
then Min quantity of MOH is 150 *2
Z : is maximum months of stock.

2. RMSD has 3 things to do

look at the form with the number of items required from MOH, and
depend
on min max qty and the quantity where RDHS stock has ,they issue
items to
MOH. They also track information of items they issued to which MOH
send the RH MIS 1158 to FHB to report remain items, issued items and
require number of new items. (same with MOH send request form to it)
After received items from FHB, RDHS need to confirm FHB that they got
the items.

3. FHB has 3 things to do

receive the request form and issue items from RMSD.
If the stock has not enough item, or need more, then it will get the
items from suppliers.
FHB also have detail information of items they got from supplier
(name,
quantity, date expiry, batch number, unit price, quantity price)
FHB issue items to RMSD. information of issue (Issue date, item
names,
quantity, date expiry, batch/lot number, unit price, quantity price,
distribute to) it can be refered from "Out put item report.JPG" file.

They want all information is save in central database, so that they
can
get all kind of report, and if there is problem with item, then they
can
generate report contain org unit were issued.

Anyway, I will work with her every afternoon so I will discuss more
and
get more information.

--
Thuy

--
Thuy

--
--
Best regards,
Kim-Anh Vo

--
--
Best regards,
Kim-Anh Vo

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to � � : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help � : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to � � : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help � : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

Hi Johan

Hi all

yes, this requirement is popping up everywhere, and we seem to be talking
about two different systems:

1) Inventory: what is available, where? stock-outs, waste rates etc
2) Logistics: procuring and distributing. Follow-up and paying

Thanks for pointing that out. Its important to keep this distinction
in mind. whereas dhis can (at a twist) function as simple inventory
system with only reporting behaviour, it doesn't have the abstractions
(and we should be wary about repurposing erxisting abstractions) to do
common logistics operations.

Can anybody say anything good or bad about this openlmis thing. It
crops up every now and again, but I can't say I know anything
substantial about it?

Regards
Bib

···

On 4 November 2010 12:09, <johansa@ifi.uio.no> wrote:

For the first, it has been quite common to use something that would work
well in DHIS2, like a table of commodities with some aggregate data like
balance, waste, used. But as Ola points out, there is a tendency that the
forms for this are extremely big, and try to function also as a surrogate
for number 2) above. If going for an inventory-solution, there are a few
useful indicators for managing the logistics, such as stock-out rates and
waste-rates, which can function quite well in adjusting the distribution
from central stores.

For a "proper" logistics system, we have all the data types and
functionalities that is typically not supported by DHIS2. Ordering,
manually or automatically, when stocks run low, following the order in the
distribution chain, and acknowledge receipt etc. An additional reuirement,
especially to combat corruption, can be to manage central stores with
bar-code systems, much like DHL or some other logistics service provider
are doing. Payment of procurements can also be envisioned as a
requirement. This is of course more tricky, but there are a few solutions
out there that at least are one their way towards this.

Like Ola said, I think going for a trimmed-down inventory solution is a
good place to start, but we should also keep track of all
requests/requirements for a logistics system, and hopefully we can start
collaborating with someone like VillageReach in Sierra Leone quite soon.

Johan

A few quick thoughts. Agree this requirement for inventory/stock
control seems to be everywhere. Maybe worth noting that the hospital
system which HISP India are basing on openmrs also has a requirement
for inventory/stock/pharmacy and someone is working on an openmrs
module for this. Might be good to harmonize efforts there but perhaps
it will be difficult. The emphasis there is on managing stores at
facility level.

On 4 November 2010 10:53, Ola Hodne Titlestad <olati@ifi.uio.no> wrote:

Hi,
Thanks to Thuy for sharing this discussion (see below my email) with all
of
us on the list.
Over the last month or so we've had many requests regarding logistics
management or supply chain systems like the one you are describing from
Sri
Lanka Thuy. It is a burning hot issue it seems and it is good to have
some
discussions around it and to think collectively on how we can support
this
in the context of a DHIS implementation.
I commented on this in a recent discussion about similar requirements
from
Uganda, and I sort of ended up with proposing 3 alternatives to them:
1) Simplify the requirements and implement it in the current version of
DHIS2
2) Build a new module for basic logistics management in DHIS2
3) Use an external software solution specialised for logistics
management
(e.g. the open source alternative OpenLMIS) and make sure you integrate
this
with DHIS2 both in terms of data exchange and facilitating easy
co-installations of both systems.
My advice would be to start with 1), and show what the current DHIS2 can
do,
and then in parallel start thinking of a more long term solution, 2) or
3).
I think given all the interest in implementing basic logistics
management in
relation to DHIS2 implementations it might be worth investigating what
2)
means in terms of what the requirements are and how much work it would
be to
do this inside DHIS2.
3) is of course a little outside our scope, at least on this list, but
it definitely seems that the sdmx-hd approach would be the way to go in
terms of data exchange. The added complexity, at least if the local
implementation team is already familiar with DHIS2, is of course to
customise and maintain a totally new software package, but I would
assume
that a specialised software package for logistics management has lots of
additional features that it probably will not make sense to include in
DHIS2.
To come back to how the current DHIS2 version could support the
requirements
you listed (which I must say are very much like what I have seen in
other
countries), can I first ask that you share the paper form with us, it
makes
it so much easier to discuss the requirements.
Anyway, as with the requirements from Uganda, there are a few things
that I
see as problematic with the current data model in DHIS.
A) How to store in the database which items that where sent where and by
whom.
E.g. when the national level sends drugs to the districts, or when
districts
sends to facilities, you write that they keep track of this information,
like what (commodity +expiry date+quantity), to whom (orgunit), and
when.
Keeping track of commodities over time and across levels is a bit
outside
the scope of the DHIS data model. While we can store how much is needed
(the
order), and how much was received, and using these also say something
about
the delivery status (delivered, not delivered, partially delivered), it
is
more tricky to store status on where each item is at a point in time, or
where they were lost.
I guess we can create a double set of data elements so that the
districts
could register data per health facility (open each health facility in
data
entry) on what has been sent to that facility, and then later the health
facility also registers (in another data set) what has actually been
received. The data element name can be used to classify whether the
commodity has been sent or received, e.g. the district will open a data
set
for a facility and only register data or the "sent" data elements,e.g.
"Condom type A sent", and then later the facility opens data entry and
registers data (for the same month) for data elements like "Condom type
A
received". Still we would be limited by a period type, I assume monthly,
and
registering the exact dates of when an item was sent and received (like
a
typical supply chain system), and then using these dates in reports etc.
will be quite complex.
B) Dealing with periods and period types and tracking orders
At least in discussions about the requirements from Uganda this became a
big
issue, and it might be here as well. A drug distribution system for a
big
country does not always follow the calendar months, and e.g. in Uganda
the
have split the country into delivery zones and for each zone they have
different start and end dates for the delivery cycles, so a 1 or 2
months
cycle of delivery, use, new order does not follow the calendar months
(Jan/Feb/Mar etc.) and hence are not periods of any DHIS period type,
which
makes data processing and reporting more complex.
If all the stock forms can follow calendar months it will be easier of
course, but still only be a monthly reporting system with monthly status
reports on stocks (orders, delivery status, stock-outs etc.). The status
on
where a drug shipment is at any point in time will be difficult to
produce
with today's data model. The "sent" dataset which stores information on
which drugs have been sent out will most likely need to have the same
period
type as the dataset with the stock balance and orders, which is monthly,
and
therefore are not that easy to use when you want to track a shipment or
order (as in finding out at which orguinit it is at any point in time).

There are probably more issues as well and it would be great if we could
systematically gathering requirements and start looking at what can be
supported and not supported in the current DHIS2 and then look at what
would
be needed to move forward with a new module for this.
So coming back to how to do option 1), to simplify the requirements and
use
the current data model of DHIS2 I would say that the requirement to
register
that drugs have been sent out needs to go. If you can reduce the
requirements to include monthly reports on what has been received, used,
and
what is needed for the next period, then I think DHIS2 can do it. Then
you
reduce the stock or delivery status to a monthly summary which shows
which
orders were completed, not completed and partially completed by
comparing
previous month's order/requests with current month's delivery/received
items.
To add some kind of notification that an order has been received and
processed it can be possible to add some additional properties or
metadata
to the form itself, or the dataset instances. You may have seen the
"Complete" button at the bottom of the data entry form, and we could
possibly add more options here, like "received by FHB (level 1)", "sent
from
FHB" etc. which would then say something about the status for the
complete
order, and not for individual line items (data elements) in the order.
These
status fields about a form (dataset+orgunit+period) can say something
about
the status of the order at any point in time and are not bound by the
limitation of the period type for the form. It will not be as accurate
as
tracing status of each drug item, but might be enough information
anyway.

A few comments on categories, forms and reports from your discussions so
far:
Data element categories to store stock data
A general rule for designing data elements and categories is to make
sure
that the sum of all the options in a category (and categorycombo) add up
to
a meaningful total. This way the total and subtotal values for a data
element are also meaningful and can be used across the system when
designing
charts, reports, maps etc. See chapter 2 in user manual for more info on
this.
However, with the stock forms and other forms of similar character
(hundreds
of rows and many columns) it seems very stupid to create data element
for
each "field" in the form, and not to use categories. You'll end up with
a
very long list of data elements just for stock data, typically with more
data elements that all the other health programs together, which makes
theCould
application slow to use and also makes it difficult to browse the data
elements list looking for non-stock data. For this reason we have
thought of
a new feature, which is to specify in the categorycombo whether it
should be
aggregated up to a total or not, whether it is "aggregatable". This will
then allow us to filter away the data elements totals and subtotals that
should not be generated since their catcombo is non-aggregatable. We
haven't
decided on all the details yet, but the point is that it will be easier
and
better to use catcombos also when the columns in the form do not add up
to a
total, like in the typical stock forms.
Calculated fields in the data entry form, e.g. "quantity required next
month"
Another related feature that we are planning is to allow for expressions
in
custom data entry forms. E.g. in the stock form many of the columns are
calculations, like the end balance, the requested number of new items
(the
order), average monthly use etc. and these are not supported at the
moment.
The idea is to include the possibility of inserting expressions into
fields
in the custom for just like you can insert data element+catoptioncombo.

Who is "we" in the above? I am not sure I agree with the new feature
proposal re aggregatable vs non aggregatable categories (catcombo is
not relevant - I guess we are talking about categories). Would have
to think more of the consequences but not now.

Expressions in forms sounds good.

- Bob

Custom reports for stock data
To comment on the reporting requirements from Sri Lanka, e.g. to list
all
orgunits that have received a specific drug that can be done using
custom
report designers like BIRT or IReport. There you will be able to produce
most types of reports and using report tables with parameters as your
data
source you can make these quite dynamic. Currently we don't have data
element as report parameter for report tables, but I guess we can find a
way
to do that as well, so that you can get a report with e.g. a list of all
orgunits at level= 3 where for data element="Condom type A",
Catoptioncombo="received", Period= "Mar-2010", and datavalue > 0.
Typically I would that it is easier to find a solution for the reporting
requirements than a good solution for how to store the data, or without
a
smart way of storing the data the reporting will be very complex and
difficult.
Would be good to start a wider discussion around these issues as these
are
quite general requirements that any country will put forward at some
point.
I don't think that there is one solution to logistics management that
will
fit all countries that already use DHIS2, as e.g whether or not to
maintain
a separate software will depend on many local factors, and how advanced
system that is needed also varies from country to country. What would be
good is to continue this discussion on how and whether DHIS2 can support
these more general requirements, and look at what steps we can take to
improve the situation, both short term and long term.

----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link
----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

On 4 November 2010 09:04, Kim-Anh Vo <catakim@gmail.com> wrote:

hello,

On Thu, Nov 4, 2010 at 1:47 PM, Thuy Nguyen >>>> <thuy.hispvietnam@gmail.com> >>>> wrote:

Hi Kim Anh,
Thanks a lot for your ideas.
There are some things I am still don't understand much. Could you
please
explain more detail about manage items. and how to create that in
current
DHIS. I still can't image how to do it using dataelement and data
entry
form.

Example

I
1. FHB receives items from supplier.
They will input the details of items as below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 100 - 50000
Condom B - CB - 03/2014 - 150 - 10000
Condom C - CC - 09/2011 - 50 - 20000

currently, DHIS2 need more development for be able to apply this.
basically and actually DHIS2 design is not for drugs management.

But for adaptation, you can just see each cell in the table as a dael.
How much items there? For only contraception program... I guess it's
really not too much, right? 100?
(name-based module is working on this: attributes,... free to add
more....
but this is just for reference and still being developed/designed...
its
purpose-the module, I mean, is not for drugs also!)

2. FHB view reports from RMDSs Report look like the 1158 form and see
that RMDS1 need 1000 condoms. So FHB issues to RMDS1 1000 condoms (A,
B, C)

thinking of separating request and return.... 2 different data-flow...
for
easy management/monitoring later.
All RMDSs report (1158 form) ---> FHB : request data-flow (equivalent
to
data-flow dataset, for example, just called:
"1158-Request-DataElementSet").
FHB issues (1158 form also) ---> RMDS(s) : return data-flow
("1158-Return-DataElementSet")

Actually, the later (return data-flow) is the core needed to monitor
data-flow. The former (request data-flow) is for recorded/checked out
later.... For example, it only does COUNT if the FHB can afford to
issue the
numbers of items, not the numbers of items in the request (following my
understanding through the project descriptions).

Possible data-entry form:
1. For request: simple request daels
2. For return: same form but showing both requested and returned/issued
daels in the same cells, just add some texts to distinguish them. This
help
the officer at FHB to monitor the request info while replying/issuing.
(the already data-input for request form will be showed in this form if
period is the same... I believe you know this too!)

3. RMDS1 receives items from FHB and input details of items they got
as
below

Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 110 - 300
Condom B - CB - 03/2014 - 160 - 200
Condom C - CC - 09/2011 - 60 - 500

the same drugs but why diff information at different level?
It's not mentioned in the descriptions of the project, right?

4. RMDS1 view reports 1158 from MOHs to see how much their MOHs want
and
see MOH11 need 500 comdoms this month. So RMDS1 issue 500 condoms (A,
B, C)
to the MOH1. (each RMDS has about 7 to 15 MOHs)

the same as point nr. 2
Dataset-report can be used in here!

5. MOH11 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom A - CA - 11/2012 - 120 - 100

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom C - CA - 11/2012 - 120 - 45

MOH15 receives items from RMDS1 and input details of items they got
Name - Code - Date exp - Unit Price - Quantity
Condom C - CC - 11/2012 - 120 - 30
Condom B - CB - 03/2014 - 160 - 50

Then my question is if we can use current DHIS, then how can we
identify
which one is data element?

Currently DHIS2, dael just consists of attributes: name, shortname,
description, etc. in one OBJECT, dataelement.
If wanting to manage each of the attribute entities: code, date exp,
etc.... JUST break it DOWN ... into dataelement
(as said in point nr. 1)

If we create Comdom A as a data element with categories options are
Name,
code, date exp, unit price, quantity is impossible. Because catgory
options
are same data type

This is a way.

If we create seperate data elements as Comdom A Name, Condom A code,
Condom A Date Exp,.. then there would be many data elements, and these
data
entry forms won't be stable because when time change, there would be
be new
kind of condom D available in the market.

It depends on the choices... how many items(drugs) of the contraceptive
stock programe?

What's the point of number of daels and stability of data-entry form?
If having more items (like condom D as you gave out), user just create
new
daels for that item.
This is a good practice of DHIS2... and because DHIS2's design is for
that.
For categories, you couldn't make changes. Moreover, category-concept
is
quite not fit in this case (non-sense for the total... you just exploit
its
by reducing daels defined).

And currently there is not Search function for data values in DHIS in
aggregated report. So if I have the Condom name, I want to generate
the list
of organistation units were got it for last 6 months. but not view in
each
org unit. Because there would be many organisation units there.

simply... as we might did here in Vietnam before maybe, add an
representative OU for all of them :wink:

I need more your explainations

These above are just my own understanding/analysis, anyone from HISP
can
help out more :slight_smile: with comments!

Thuy
---------- Forwarded message ----------
From: Kim-Anh Vo <catakim@gmail.com>
Date: Thu, Nov 4, 2010 at 10:31 AM
Subject: Re: New requirement from Sri Lanka
To: Thuy Nguyen <thuy.hispvietnam@gmail.com>

hello again,

That's really interesting... as I guess.
DHIS2 is possible to be customized for monitoring items through
levels.

Data:
There are two data-flow to be kept in mind: upward (request) and
downward
(return).
They're all the input-data indeed!
So we need 2 collection of daels (categories also) with request/return
as
the identifiers.

Services: all functions taken place by calculation/modification/...
between these two data-flow. Eg: reports (aggregated input data - the
same
form for input data up/downward and output, and monitoring purpose as
well),
analysis by chart, GIS.
With BIRT + reporttable concept (DHIS2): almost report-issues have
clues
for solution.

Keep it as simple as possible :slight_smile:

Let me know how he project is going in the future.
I'm interested the practical uses/customizations of DHIS2 like this!

On Thu, Nov 4, 2010 at 10:27 AM, Thuy Nguyen >>>>> <thuy.hispvietnam@gmail.com> >>>>> wrote:

---------- Forwarded message ----------
From: Thuy Nguyen <thuy.hispvietnam@gmail.com>
Date: Tue, Nov 2, 2010 at 3:44 AM
Subject: Re: New requirement from Sri Lanka
To: John lewis <johnlewis.hisp@gmail.com>

I was sleeping but wake up in the night and can't stop thinking of
the
project. Let me describ more about the process of existing system.
There was
an activity diagram but the doc she sent me by docx, i can't see any
table
in that. I will send you tomorrow.

Level 1 National : FHB

Level 2 District : RMSD

Level 3 Division : MOH

The process from bottom to top

1. the MOH send the request form to RMSD. The form has code RH MIS
1158
(Monthly Contraceptive Strock Return/Request form) as I sent in
previous
email.First of all

This form has information of

Month - Year send request
Places the form would be sent to
The main area of the form has a table with

row is : condom, oral pill packet, injectables (DBMA) vials, intra
uterine device and implants
column is :

Amount remain at the end of last month (a),
amount received during a month,
total
amount issued/despensed during the month,
amount remain at the end of the month
amount require
average monthly requirement :
min qty
max qty: depend on the need of that stock.

(3) = (1)+(2)
(4)
(5) = (3)-(4)
(5) -> (1) in next month
(6)=(8)-(5)
(7)= (sum (4) ) / Xmonths
(8)= Y * (7)
(9) = Z * (7)

X : is number of months ( but atleast 3 months, or 6 months, 12
months,...)
Y : is minimum months of stock (Mos) that the specified org unit need
to
store. Example the min of MOH is 2 months of store. So if the (7) is
150.
then Min quantity of MOH is 150 *2
Z : is maximum months of stock.

2. RMSD has 3 things to do

look at the form with the number of items required from MOH, and
depend
on min max qty and the quantity where RDHS stock has ,they issue
items to
MOH. They also track information of items they issued to which MOH
send the RH MIS 1158 to FHB to report remain items, issued items and
require number of new items. (same with MOH send request form to it)
After received items from FHB, RDHS need to confirm FHB that they got
the items.

3. FHB has 3 things to do

receive the request form and issue items from RMSD.
If the stock has not enough item, or need more, then it will get the
items from suppliers.
FHB also have detail information of items they got from supplier
(name,
quantity, date expiry, batch number, unit price, quantity price)
FHB issue items to RMSD. information of issue (Issue date, item
names,
quantity, date expiry, batch/lot number, unit price, quantity price,
distribute to) it can be refered from "Out put item report.JPG" file.

They want all information is save in central database, so that they
can
get all kind of report, and if there is problem with item, then they
can
generate report contain org unit were issued.

Anyway, I will work with her every afternoon so I will discuss more
and
get more information.

--
Thuy

--
Thuy

--
--
Best regards,
Kim-Anh Vo

--
--
Best regards,
Kim-Anh Vo

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

Hi all,

I attached the functional requirements documentations. Do you think that if there is any way of customize DHIS for these functions?

As I looked at the database of items which the person who work on this thesis created. There are so many items. It may up to hundreds. Condom type A would have many items, according to difference of expiry date, batch codes there would be difference items. And there is not only about condom, but also oral pill packages, injectable vials, Intra uterine device, and implants. So I think the way of creating data element as Condom type A, condom type B using DHIS can’t be done. More over, if we simplify the requirement until name only. Then there is a problem this year may be they import and distribute condom type A, but next year they don’t, and next next year they again use condom type A.

Because of the complicated of this so at the moment, we decided to use DHIS for the aggregated report 1158 and collect data values and create other types of reports which existing in DHIS. And mean while, we will see how openlms work and decide how can DHIS will be customized or use another application for these requirements.

1. Exsiting system Functional requirement.doc (33 KB)

4.Functional requirment proposed system.doc (48.5 KB)

···


Thuy

Dear all,

According to the aggregating report RHMIS1158 and requirements described. I create the system in DHIS as below. Please see if I doing right, or DHIS need a new function in aggregated way.
I created 5 data elements

  • Condom,

  • Oral Pill packet,

  • Injectables Vials,

  • Intra Uterine device,

  • Implants.
    All these dataelements would be assigned with category combination include 4 category options are :

  • Amount at the end of lastmonth,

  • Amount received during the month,

  • Amount issued during the month,

  • and Average monthly requirement.

Those data elements were in a dataset for all organistaion unit levels enter data. Because all of them need to update their stores. But by doing as described above, there are problems:

  1. The system require that the upper level shouldn’t see data entry form or edit data values of lower levels. To solve this, I create different datasets contain above data elements and assign to different organisation unit levels.

  2. However, when generate report, because DHIS aggregated data from bottom to top org unit levels. So the parent org unit can’t view their own data values but total values included their values and their children’s values. And data would be double a lot because example for data element Condom received during the month. parent orgunit received 100, then they issued 100. The children org unit will received 100. So after aggregated, the total received will be 200. This is not right.

And in report, they just want to view seperate org unit level total but not aggregate from bottom to top. And it was a little bit difficult when parent org unit will want to see their values OR children org unit values, not include total of their grandchildren orgunit level values

So I created more data elements for different org unit levels. Such as
Parent OrgUnit - Condom(received during the month) (in dataset of parent org unit)
Children OrgUnit - Condom(received during the month) (in dataset of children org unit)

GrandChildren OrgUnit - Condom(received during the month) (in dataset of grandchildren ort unit)
For this, I can seperate the org unit levels to not view and edit data values of others. As well as generate report without total of multi org unit levels.

But I wonder if this is the right way to store data? by this way will we face any problem in the future? If this is not the right way, then how should I create the reports to satisfy report viewing requirement? I know that in data element has a check box for aggregated at level… but that is only for temporary use. and in this case the aggregated of org unit level is not stable to use that. Should we have selections to select which level to aggregate while design/generate report?

Those are doubts in my mind. I am not much sure what I am doing is right or wrong because I don’t have much experience about retrieving data values and analysis later. So I hope you have experience about that help me to see the problems may happen if I do this way or that way to store data.

Thank you very much

Thuy

image

LogicsticManagementSystem.zip (436 KB)

Dear Thuy,

I'm not very familiar with the requirements in Sri Lanka, but I have a few
general comments. First, the categories and combinations should be used
when we want to aggregate them into a data element that is a natural total
of these categories. For stock, this is usually not the case, as we do not
want to add start balance, received, issued, and monthly requirement (in
this case). The total will be meaningless. The average monthly requirement
would probably also be a semipermanent data element I think.

Second, regarding the parent/child/grandchild totals, I think it should be
possible to set aggregation start levels, meaning you could use the same
data element definitions for all levels without running into double/triple
counting. But others would need to fill in about this.

Aside from this, I would recommend some changes to the form attached, if
possible. If these forms are not final, I would recommend adding some
aggregate information on stock outs, such as days out of stock. But if
this is generally not a problem, then the few instances can be derived
from the other data elements.

Regards,
Johan

···

Dear all,

According to the aggregating report RHMIS1158 and requirements described.
I
create the system in DHIS as below. Please see if I doing right, or DHIS
need a new function in aggregated way.
I created 5 data elements
- Condom,
- Oral Pill packet,
- Injectables Vials,
- Intra Uterine device,
- Implants.
All these dataelements would be assigned with category combination include
4
category options are :
- Amount at the end of lastmonth,
- Amount received during the month,
- Amount issued during the month,
- and Average monthly requirement.

Those data elements were in a dataset for all organistaion unit levels
enter
data. Because all of them need to update their stores. But by doing as
described above, there are problems:

1. The system require that the upper level shouldn't see data entry form
or
edit data values of lower levels. To solve this, I create different
datasets
contain above data elements and assign to different organisation unit
levels.

2. However, when generate report, because DHIS aggregated data from bottom
to top org unit levels. So the parent org unit can't view their own data
values but total values included their values and their children's values.
And data would be double a lot because example for data element Condom
received during the month. parent orgunit received 100, then they issued
100. The children org unit will received 100. So after aggregated, the
total
received will be 200. This is not right.

And in report, they just want to view seperate org unit level total but
not
aggregate from bottom to top. And it was a little bit difficult when
parent
org unit will want to see their values OR children org unit values, not
include total of their grandchildren orgunit level values

So I created more data elements for different org unit levels. Such as
Parent OrgUnit - Condom(received during the month) (in dataset of parent
org unit)
Children OrgUnit - Condom(received during the month) (in dataset of
children
org unit)
GrandChildren OrgUnit - Condom(received during the month) (in dataset of
grandchildren ort unit)
For this, I can seperate the org unit levels to not view and edit data
values of others. As well as generate report without total of multi org
unit
levels.

But I wonder if this is the right way to store data? by this way will we
face any problem in the future? If this is not the right way, then how
should I create the reports to satisfy report viewing requirement? I know
that in data element has a check box for aggregated at level.. but that is
only for temporary use. and in this case the aggregated of org unit level
is
not stable to use that. Should we have selections to select which level to
aggregate while design/generate report?

Those are doubts in my mind. I am not much sure what I am doing is right
or
wrong because I don't have much experience about retrieving data values
and
analysis later. So I hope you have experience about that help me to see
the
problems may happen if I do this way or that way to store data.

Thank you very much

Thuy

Dear Johan,
Thank you for your suggestions. Please scroll down to see my mail

Dear Thuy,

I’m not very familiar with the requirements in Sri Lanka, but I have a few

general comments. First, the categories and combinations should be used

when we want to aggregate them into a data element that is a natural total

of these categories. For stock, this is usually not the case, as we do not

want to add start balance, received, issued, and monthly requirement (in

this case).

About the total meaning of categories and categories options. I got the lesson from my mistake in Vietnam. So I didn’t want to repeat again by explanation people here. But again because of the instant benefit of category data elements such as the defaul entry form will generate automatically with good form which DHIS provided. And the shorting of creating data elements,… So the person who do this project decided to use categories for this report as well as other reports for equipments like beds, tables,… I knew it is wrong for the meaning of categories which developers in DHIS wish to use. But I don’t know serious reason for defense on this. That’s why I consult you to know what will happen in the future when data base become huge if we use category options like this for data elements? Is it affecting to retrieving information later?

The total will be meaningless. The average monthly requirement

would probably also be a semipermanent data element I think.

Tihs averate number is calculated like this. it will get total values of 12 months issued in the year and devise to 12. Some places they get total of last 3 months and devise to 3. Some places use total of last 6 months and devise to 6. This is according to each place prediction for their requirements to get the items.

And when the data base in very start state, there is not value of last months. But the requirement need to be generated.

That’s why I put more element for average, users will enter the values they want according to their requirements. This average require and depend on the size of each place’s stock, will generate min require quantity, max require quantity.

Second, regarding the parent/child/grandchild totals, I think it should be

possible to set aggregation start levels, meaning you could use the same

data element definitions for all levels without running into double/triple

counting. But others would need to fill in about this.

I don’t understand much about this. Please give more suggestions.

Aside from this, I would recommend some changes to the form attached, if

possible. If these forms are not final, I would recommend adding some

aggregate information on stock outs, such as days out of stock. But if

this is generally not a problem, then the few instances can be derived

from the other data elements.

Regards,

Johan

Thuy

···

On Tue, Dec 7, 2010 at 1:59 AM, johansa@ifi.uio.no wrote:

Hi Thuy,

I personally think one has to weight these things against each other.
I understand very well the desire to have nice autogenerated forms,
and I don't really see the big problem with using categories this way
AS LONG AS one bears in mind that the total will not work. I think the
major downside to doing it like this is that Pivot tables will not
work well on these dataelements, since the whole point of pivot tables
is to easily sum up - and if some of the sums are meaningless, that
restricts the usefulness of the pivot tables.

It would be nice if it were possible to easily generate good looking
forms without violating the semantics of the aggregation model, though
I suppose that would require a decoupling of the form section
generating machinery from the data element model. One would then be
able to assign categorycombos to a section, but also group data
elements in sections external to the disaggregation model.

Knut

···

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@gmail.com> wrote:

Dear Johan,
Thank you for your suggestions. Please scroll down to see my mail

On Tue, Dec 7, 2010 at 1:59 AM, <johansa@ifi.uio.no> wrote:

Dear Thuy,

I'm not very familiar with the requirements in Sri Lanka, but I have a few
general comments. First, the categories and combinations should be used
when we want to aggregate them into a data element that is a natural total
of these categories. For stock, this is usually not the case, as we do not
want to add start balance, received, issued, and monthly requirement (in
this case).

About the total meaning of categories and categories options. I got the
lesson from my mistake in Vietnam. So I didn't want to repeat again by
explanation people here. But again because of the instant benefit of
category data elements such as the defaul entry form will generate
automatically with good form which DHIS provided. And the shorting of
creating data elements,... So the person who do this project decided to use
categories for this report as well as other reports for equipments like
beds, tables,... I knew it is wrong for the meaning of categories which
developers in DHIS wish to use. But I don't know serious reason for defense
on this. That's why I consult you to know what will happen in the future
when data base become huge if we use category options like this for data
elements? Is it affecting to retrieving information later?

This has got me thinking once again what a category/combo/option
actually is and how the current implementation makes too many
assumptions, like that categories should add up to a total.

I would suggest we continue thinking about it in background document
I created a while back..

···

On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <knutst@gmail.com> wrote:

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@gmail.com> wrote:

Dear Johan,
Thank you for your suggestions. Please scroll down to see my mail

On Tue, Dec 7, 2010 at 1:59 AM, <johansa@ifi.uio.no> wrote:

Dear Thuy,

I'm not very familiar with the requirements in Sri Lanka, but I have a few
general comments. First, the categories and combinations should be used
when we want to aggregate them into a data element that is a natural total
of these categories. For stock, this is usually not the case, as we do not
want to add start balance, received, issued, and monthly requirement (in
this case).

About the total meaning of categories and categories options. I got the
lesson from my mistake in Vietnam. So I didn't want to repeat again by
explanation people here. But again because of the instant benefit of
category data elements such as the defaul entry form will generate
automatically with good form which DHIS provided. And the shorting of
creating data elements,... So the person who do this project decided to use
categories for this report as well as other reports for equipments like
beds, tables,... I knew it is wrong for the meaning of categories which
developers in DHIS wish to use. But I don't know serious reason for defense
on this. That's why I consult you to know what will happen in the future
when data base become huge if we use category options like this for data
elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.
I understand very well the desire to have nice autogenerated forms,
and I don't really see the big problem with using categories this way
AS LONG AS one bears in mind that the total will not work. I think the
major downside to doing it like this is that Pivot tables will not
work well on these dataelements, since the whole point of pivot tables
is to easily sum up - and if some of the sums are meaningless, that
restricts the usefulness of the pivot tables.

It would be nice if it were possible to easily generate good looking
forms without violating the semantics of the aggregation model, though
I suppose that would require a decoupling of the form section
generating machinery from the data element model. One would then be
able to assign categorycombos to a section, but also group data
elements in sections external to the disaggregation model.

Knut

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

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

Dear Thuy

Dear Johan,
Thank you for your suggestions. Please scroll down to see my mail

on this. That's why I consult you to know what will happen in the future
when data base become huge if we use category options like this for data
elements? Is it affecting to retrieving information later?

I don't know too much about this, but think Knut sums it up. The only
obvious place that I see where this can cause problems is in pivot tables.
Since pivot tables usually are distributed to also those not too familiar
with the database setup, this can be confusing.

Second, regarding the parent/child/grandchild totals, I think it should
be
possible to set aggregation start levels, meaning you could use the same
data element definitions for all levels without running into
double/triple
counting. But others would need to fill in about this.

I don't understand much about this. Please give more suggestions.

Here also I'm not 100% sure, but if you go to edit data element, you will
find the Aggregation Level check box, which if checked will produce a
drop-down list of all the levels you can aggregate data from. From the
manual:

"Aggregation levels: The Aggregation Levels option allows the data element
to be aggregated at one or more
levels. When the user clicks on the Aggregation levels option, a drop down
menu appears which displays available
aggregation levels. The desired aggregation level is then selected by
clicking the �Add Selected� button. By default,
the aggregation will start at the lowest assigned organisation unit."

I'm not sure if this adequately explains the funcionality. Others would
need to help here, but I *think* this is working by setting the levels
that will use "it's own" data rather than aggregate from below. Default
only the lowest level is selected, and all higher levels will use data
from that level. For example, if you have three levels; Facility,
District, National, the last two levels will by default aggregate the data
from Facility. If you select District as aggregation level, queries on
Facility will use Facility data, District will use District Data, and
National will aggregate District data. So in the Sri Lanka case, you can
have one data element that you can use for all levels, just set it to have
all aggregation levels. But not 100% sure about this, so good if someone
can confirm. Also not sure aggregation level is the best name, I vaguely
remember some discussion about this.

Regards,
Johan

there seem to be 3 primary motivations for an implementor to use categories
(i) it can make auto-generated forms do what you want
(ii) it reduces the number of dataelements you have to design
(iii) it provides an axis for analysis

In the best of cases these three conspire together to produce a good
result. eg datavalues which are collected disaggregated by sex.

In other cases the benefits of (i) are so compelling that the fact
that (iii) is not consistent is not considered. I've seen a few
proposed solutions to this (I think most recently a setting which
indicates whether a category is a "summing" category or not). Not
sure if I'm too happy with any of them, but one observation is that in
almost all cases I've seen this occur, it is related to
stock/inventory. This might just be a coincidence but sure looks like
a pattern to me. perhaps there might be a point in recognizing the
special case of inventory and make a small inventory module rather
than handling through "standard" data entry.

Looking at the 4 categoryoptions there is an opening balance, amount
issued, amount received and avg monthly requirement in each case. As
well as stock reorder amounts etc associated with each dataelement.
Thuy seems to have done a good job in removing some of the extra
calculated values. Though I am not sure about average monthly
requirement. is that really an observation or is it calculated
somehow? And how do we persist things like the min/max amounts etc.
Anyway there seems to be a particular and repeated logic which drives
these stock/inventory dataelements. A stock/inventory module could
provide form layout based on that logic rather than on categorycombo.
As well as some extra data attributes for inventory related stuff
which would not be what we would term datelement.

From analysis perspective the fewer the categories the better, reusing

categories is good and categories which don't add up are bad as they
create confusion and complication at the output end.

From UI perspective, unless we can provide an alternative simple way

of achieving the simple tabular layout, users will continue to (ab)use
the categories for this. The labour saving is really just too much.

Sorry Thuy this is a bit of a distrasction from your initial question,
which I see Johan is addressing :slight_smile:

Cheers
Bob

···

On 7 December 2010 08:23, Jason Pickering <jason.p.pickering@gmail.com> wrote:

This has got me thinking once again what a category/combo/option
actually is and how the current implementation makes too many
assumptions, like that categories should add up to a total.

I would suggest we continue thinking about it in background document
I created a while back..

Categories concept paper.doc - Google Docs

On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <knutst@gmail.com> wrote:

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@gmail.com> wrote:

Dear Johan,
Thank you for your suggestions. Please scroll down to see my mail

On Tue, Dec 7, 2010 at 1:59 AM, <johansa@ifi.uio.no> wrote:

Dear Thuy,

I'm not very familiar with the requirements in Sri Lanka, but I have a few
general comments. First, the categories and combinations should be used
when we want to aggregate them into a data element that is a natural total
of these categories. For stock, this is usually not the case, as we do not
want to add start balance, received, issued, and monthly requirement (in
this case).

About the total meaning of categories and categories options. I got the
lesson from my mistake in Vietnam. So I didn't want to repeat again by
explanation people here. But again because of the instant benefit of
category data elements such as the defaul entry form will generate
automatically with good form which DHIS provided. And the shorting of
creating data elements,... So the person who do this project decided to use
categories for this report as well as other reports for equipments like
beds, tables,... I knew it is wrong for the meaning of categories which
developers in DHIS wish to use. But I don't know serious reason for defense
on this. That's why I consult you to know what will happen in the future
when data base become huge if we use category options like this for data
elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.
I understand very well the desire to have nice autogenerated forms,
and I don't really see the big problem with using categories this way
AS LONG AS one bears in mind that the total will not work. I think the
major downside to doing it like this is that Pivot tables will not
work well on these dataelements, since the whole point of pivot tables
is to easily sum up - and if some of the sums are meaningless, that
restricts the usefulness of the pivot tables.

It would be nice if it were possible to easily generate good looking
forms without violating the semantics of the aggregation model, though
I suppose that would require a decoupling of the form section
generating machinery from the data element model. One would then be
able to assign categorycombos to a section, but also group data
elements in sections external to the disaggregation model.

Knut

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

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

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

This explanation is correct. It is a lot more in the manual than what Johan pasted, see 10.2.1.5 (Aggregation Levels).

Ola

···

On 7 December 2010 09:48, johansa@ifi.uio.no wrote:

Dear Thuy

Dear Johan,

Thank you for your suggestions. Please scroll down to see my mail

on this. That’s why I consult you to know what will happen in the future

when data base become huge if we use category options like this for data

elements? Is it affecting to retrieving information later?

I don’t know too much about this, but think Knut sums it up. The only

obvious place that I see where this can cause problems is in pivot tables.

Since pivot tables usually are distributed to also those not too familiar

with the database setup, this can be confusing.

Second, regarding the parent/child/grandchild totals, I think it should

be

possible to set aggregation start levels, meaning you could use the same

data element definitions for all levels without running into

double/triple

counting. But others would need to fill in about this.

I don’t understand much about this. Please give more suggestions.

Here also I’m not 100% sure, but if you go to edit data element, you will

find the Aggregation Level check box, which if checked will produce a

drop-down list of all the levels you can aggregate data from. From the

manual:

"Aggregation levels: The Aggregation Levels option allows the data element

to be aggregated at one or more

levels. When the user clicks on the Aggregation levels option, a drop down

menu appears which displays available

aggregation levels. The desired aggregation level is then selected by

clicking the ‘Add Selected’ button. By default,

the aggregation will start at the lowest assigned organisation unit."

I’m not sure if this adequately explains the funcionality. Others would

need to help here, but I think this is working by setting the levels

that will use “it’s own” data rather than aggregate from below. Default

only the lowest level is selected, and all higher levels will use data

from that level. For example, if you have three levels; Facility,

District, National, the last two levels will by default aggregate the data

from Facility. If you select District as aggregation level, queries on

Facility will use Facility data, District will use District Data, and

National will aggregate District data. So in the Sri Lanka case, you can

have one data element that you can use for all levels, just set it to have

all aggregation levels. But not 100% sure about this, so good if someone

can confirm. Also not sure aggregation level is the best name, I vaguely

remember some discussion about this.


Regards,

Johan

I have previously been very defensive of the “must add up to a total” rule, but over the last months I have changed my mind here.

There are some use cases, and we keep seeing more and more of these, especially with stock, where you will quickly end up with 500+ data elements in a flat data element model for just one form, which might be more than all the other data elements together. Your list of data elements will get polluted, all browsing that involves data elements will be more difficult. And of course being able to automatically get that nice tabular form is a major bonus, although I tend to think of the very long data element lists as a worse effect of this than the extra one-off work of designing the form.

I have discussed this with Lars in the past and I think many of us agree that the current use of the model is not ideal, we should not tie the model this closely to the presentation layer and we have said before on this list that we should look at a better data entry form model in the future. But this will take time and is not realistic to get in place for another 6 months at least.

While waiting for a better model I agree with Knut that we can use the categories to reduce the number of data elements and to get the auto-generated form even though the options don’t add up to a meaningful total. Of course then we must make sure that this total is never used in a report, validation rule, or indicator expression etc. One way to do this is to add a property on the category that says “non-aggregatable” or similar, to indicate that we never want to use the aggregated total. This way we can filter away the totals in indicator formula editors etc. (Lars implemented the use of totals there yesterday).

Pivot tables is another issue I guess, since we cannot control the aggregation in the same way, since the users can zoom in and out as they want. But if we always provide the catoptioncombo field in the pivot tables, as we do today, the users will easily see, if they want, the raw data below the total. There are other dimensions in the pivot table that are not aggregatable (I think Lars googled this word and found it to be existing…), like DataElement and Indicator, and the totals for these do not make sense either. Of course the pivots will be a lot better and easier to use when the totals for data elements actually are useful, so that we don’t have to show all the options all the time. We can create filters so that stock data (or non-aggregatable data) is not part of the core pivot tables and create separate special tables for these, or just trust that the users will do this filtering themselves, and understand what the totals mean and not mean.

Ola

···

On 7 December 2010 09:02, Knut Staring knutst@gmail.com wrote:

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Dear Johan,

Thank you for your suggestions. Please scroll down to see my mail

On Tue, Dec 7, 2010 at 1:59 AM, johansa@ifi.uio.no wrote:

Dear Thuy,

I’m not very familiar with the requirements in Sri Lanka, but I have a few

general comments. First, the categories and combinations should be used

when we want to aggregate them into a data element that is a natural total

of these categories. For stock, this is usually not the case, as we do not

want to add start balance, received, issued, and monthly requirement (in

this case).

About the total meaning of categories and categories options. I got the

lesson from my mistake in Vietnam. So I didn’t want to repeat again by

explanation people here. But again because of the instant benefit of

category data elements such as the defaul entry form will generate

automatically with good form which DHIS provided. And the shorting of

creating data elements,… So the person who do this project decided to use

categories for this report as well as other reports for equipments like

beds, tables,… I knew it is wrong for the meaning of categories which

developers in DHIS wish to use. But I don’t know serious reason for defense

on this. That’s why I consult you to know what will happen in the future

when data base become huge if we use category options like this for data

elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.

I understand very well the desire to have nice autogenerated forms,

and I don’t really see the big problem with using categories this way

AS LONG AS one bears in mind that the total will not work. I think the

major downside to doing it like this is that Pivot tables will not

work well on these dataelements, since the whole point of pivot tables

is to easily sum up - and if some of the sums are meaningless, that

restricts the usefulness of the pivot tables.


It would be nice if it were possible to easily generate good looking

forms without violating the semantics of the aggregation model, though

I suppose that would require a decoupling of the form section

generating machinery from the data element model. One would then be

able to assign categorycombos to a section, but also group data

elements in sections external to the disaggregation model.

Knut

Dear Johan,

Thank you for your suggestions. Please scroll down to see my mail

Dear Thuy,

I’m not very familiar with the requirements in Sri Lanka, but I have a few

general comments. First, the categories and combinations should be used

when we want to aggregate them into a data element that is a natural total

of these categories. For stock, this is usually not the case, as we do not

want to add start balance, received, issued, and monthly requirement (in

this case).

About the total meaning of categories and categories options. I got the

lesson from my mistake in Vietnam. So I didn’t want to repeat again by

explanation people here. But again because of the instant benefit of

category data elements such as the defaul entry form will generate

automatically with good form which DHIS provided. And the shorting of

creating data elements,… So the person who do this project decided to use

categories for this report as well as other reports for equipments like

beds, tables,… I knew it is wrong for the meaning of categories which

developers in DHIS wish to use. But I don’t know serious reason for defense

on this. That’s why I consult you to know what will happen in the future

when data base become huge if we use category options like this for data

elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.

I understand very well the desire to have nice autogenerated forms,

and I don’t really see the big problem with using categories this way

AS LONG AS one bears in mind that the total will not work. I think the

major downside to doing it like this is that Pivot tables will not

work well on these dataelements, since the whole point of pivot tables

is to easily sum up - and if some of the sums are meaningless, that

restricts the usefulness of the pivot tables.

I have previously been very defensive of the “must add up to a total” rule, but over the last months I have changed my mind here.

There are some use cases, and we keep seeing more and more of these, especially with stock, where you will quickly end up with 500+ data elements in a flat data element model for just one form, which might be more than all the other data elements together. Your list of data elements will get polluted, all browsing that involves data elements will be more difficult. And of course being able to automatically get that nice tabular form is a major bonus, although I tend to think of the very long data element lists as a worse effect of this than the extra one-off work of designing the form.

I have discussed this with Lars in the past and I think many of us agree that the current use of the model is not ideal, we should not tie the model this closely to the presentation layer and we have said before on this list that we should look at a better data entry form model in the future. But this will take time and is not realistic to get in place for another 6 months at least.

While waiting for a better model I agree with Knut that we can use the categories to reduce the number of data elements and to get the auto-generated form even though the options don’t add up to a meaningful total. Of course then we must make sure that this total is never used in a report, validation rule, or indicator expression etc. One way to do this is to add a property on the category that says “non-aggregatable” or similar, to indicate that we never want to use the aggregated total. This way we can filter away the totals in indicator formula editors etc. (Lars implemented the use of totals there yesterday).

Pivot tables is another issue I guess, since we cannot control the aggregation in the same way, since the users can zoom in and out as they want. But if we always provide the catoptioncombo field in the pivot tables, as we do today, the users will easily see, if they want, the raw data below the total. There are other dimensions in the pivot table that are not aggregatable (I think Lars googled this word and found it to be existing…), like DataElement and Indicator, and the totals for these do not make sense either. Of course the pivots will be a lot better and easier to use when the totals for data elements actually are useful, so that we don’t have to show all the options all the time. We can create filters so that stock data (or non-aggregatable data) is not part of the core pivot tables and create separate special tables for these, or just trust that the users will do this filtering themselves, and understand what the totals mean and not mean.

Ola


sorry, hadn’t seen Bob’s post when I wrote this.

···

On 7 December 2010 11:08, Ola Hodne Titlestad olati@ifi.uio.no wrote:

On 7 December 2010 09:02, Knut Staring knutst@gmail.com wrote:

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

On Tue, Dec 7, 2010 at 1:59 AM, johansa@ifi.uio.no wrote:

It would be nice if it were possible to easily generate good looking

forms without violating the semantics of the aggregation model, though

I suppose that would require a decoupling of the form section

generating machinery from the data element model. One would then be

able to assign categorycombos to a section, but also group data

elements in sections external to the disaggregation model.

Knut

> Dear Johan,
> Thank you for your suggestions. Please scroll down to see my mail
>
>
>
>>
>> Dear Thuy,
>>
>> I'm not very familiar with the requirements in Sri Lanka, but I have a
>> few
>> general comments. First, the categories and combinations should be used
>> when we want to aggregate them into a data element that is a natural
>> total
>> of these categories. For stock, this is usually not the case, as we do
>> not
>> want to add start balance, received, issued, and monthly requirement
>> (in
>> this case).
>
> About the total meaning of categories and categories options. I got the
> lesson from my mistake in Vietnam. So I didn't want to repeat again by
> explanation people here. But again because of the instant benefit of
> category data elements such as the defaul entry form will generate
> automatically with good form which DHIS provided. And the shorting of
> creating data elements,... So the person who do this project decided to
> use
> categories for this report as well as other reports for equipments like
> beds, tables,... I knew it is wrong for the meaning of categories which
> developers in DHIS wish to use. But I don't know serious reason for
> defense
> on this. That's why I consult you to know what will happen in the future
> when data base become huge if we use category options like this for data
> elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.
I understand very well the desire to have nice autogenerated forms,
and I don't really see the big problem with using categories this way
AS LONG AS one bears in mind that the total will not work. I think the
major downside to doing it like this is that Pivot tables will not
work well on these dataelements, since the whole point of pivot tables
is to easily sum up - and if some of the sums are meaningless, that
restricts the usefulness of the pivot tables.

I have previously been very defensive of the "must add up to a total" rule,
but over the last months I have changed my mind here.
There are some use cases, and we keep seeing more and more of these,
especially with stock,

Out of curiosity, how much of this is with stock?

···

On 7 December 2010 10:08, Ola Hodne Titlestad <olati@ifi.uio.no> wrote:

On 7 December 2010 09:02, Knut Staring <knutst@gmail.com> wrote:

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@gmail.com> >> wrote:
> On Tue, Dec 7, 2010 at 1:59 AM, <johansa@ifi.uio.no> wrote:

where you will quickly end up with 500+ data elements
in a flat data element model for just one form, which might be more than all
the other data elements together. Your list of data elements will get
polluted, all browsing that involves data elements will be more difficult.
And of course being able to automatically get that nice tabular form is a
major bonus, although I tend to think of the very long data element lists as
a worse effect of this than the extra one-off work of designing the form.
I have discussed this with Lars in the past and I think many of us agree
that the current use of the model is not ideal, we should not tie the model
this closely to the presentation layer and we have said before on this list
that we should look at a better data entry form model in the future. But
this will take time and is not realistic to get in place for another 6
months at least.
While waiting for a better model I agree with Knut that we can use the
categories to reduce the number of data elements and to get the
auto-generated form even though the options don't add up to a meaningful
total. Of course then we must make sure that this total is never used in a
report, validation rule, or indicator expression etc. One way to do this is
to add a property on the category that says "non-aggregatable" or similar,
to indicate that we never want to use the aggregated total. This way we can
filter away the totals in indicator formula editors etc. (Lars implemented
the use of totals there yesterday).
Pivot tables is another issue I guess, since we cannot control the
aggregation in the same way, since the users can zoom in and out as they
want. But if we always provide the catoptioncombo field in the pivot tables,
as we do today, the users will easily see, if they want, the raw data below
the total. There are other dimensions in the pivot table that are not
aggregatable (I think Lars googled this word and found it to be existing..),
like DataElement and Indicator, and the totals for these do not make sense
either. Of course the pivots will be a lot better and easier to use when the
totals for data elements actually are useful, so that we don't have to show
all the options all the time. We can create filters so that stock data (or
non-aggregatable data) is not part of the core pivot tables and create
separate special tables for these, or just trust that the users will do this
filtering themselves, and understand what the totals mean and not mean.

Ola
---------

It would be nice if it were possible to easily generate good looking
forms without violating the semantics of the aggregation model, though
I suppose that would require a decoupling of the form section
generating machinery from the data element model. One would then be
able to assign categorycombos to a section, but also group data
elements in sections external to the disaggregation model.

Knut

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

there seem to be 3 primary motivations for an implementor to use categories

(i) it can make auto-generated forms do what you want

(ii) it reduces the number of dataelements you have to design

(iii) it provides an axis for analysis

In the best of cases these three conspire together to produce a good

result. eg datavalues which are collected disaggregated by sex.

In other cases the benefits of (i) are so compelling that the fact

that (iii) is not consistent is not considered. I’ve seen a few

proposed solutions to this (I think most recently a setting which

indicates whether a category is a “summing” category or not). Not

sure if I’m too happy with any of them, but one observation is that in

almost all cases I’ve seen this occur, it is related to

stock/inventory. This might just be a coincidence but sure looks like

a pattern to me. perhaps there might be a point in recognizing the

special case of inventory and make a small inventory module rather

than handling through “standard” data entry.

In Kenya it is actually the human resources form that is the problem. They repeat 10 columns (that do not add up) over about 40-50 different cadres, so many data elements.

But I agree that stock forms are the most common one and that we should look into better support for logistics functionality, at least the simpler inventory stuff that is close to our model anyway.

I think we have put “use of calculated expressions in custom data entry” on the roadmap somewhere. These will then provide a tools for adding more complex calculations that are needed in the form. Of course if we limit this functionality to the custom forms, which seems easier and less complex, then we can’t use the auto-generated forms anyway…

Ola

···

On 7 December 2010 10:41, Bob Jolliffe bobjolliffe@gmail.com wrote:

Looking at the 4 categoryoptions there is an opening balance, amount

issued, amount received and avg monthly requirement in each case. As

well as stock reorder amounts etc associated with each dataelement.

Thuy seems to have done a good job in removing some of the extra

calculated values. Though I am not sure about average monthly

requirement. is that really an observation or is it calculated

somehow? And how do we persist things like the min/max amounts etc.

Anyway there seems to be a particular and repeated logic which drives

these stock/inventory dataelements. A stock/inventory module could

provide form layout based on that logic rather than on categorycombo.

As well as some extra data attributes for inventory related stuff

which would not be what we would term datelement.

From analysis perspective the fewer the categories the better, reusing

categories is good and categories which don’t add up are bad as they

create confusion and complication at the output end.

From UI perspective, unless we can provide an alternative simple way

of achieving the simple tabular layout, users will continue to (ab)use

the categories for this. The labour saving is really just too much.

Sorry Thuy this is a bit of a distrasction from your initial question,

which I see Johan is addressing :slight_smile:

Cheers

Bob

On 7 December 2010 08:23, Jason Pickering jason.p.pickering@gmail.com wrote:

This has got me thinking once again what a category/combo/option

actually is and how the current implementation makes too many

assumptions, like that categories should add up to a total.

I would suggest we continue thinking about it in background document

I created a while back…

https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en

On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring knutst@gmail.com wrote:

On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Dear Johan,

Thank you for your suggestions. Please scroll down to see my mail

On Tue, Dec 7, 2010 at 1:59 AM, johansa@ifi.uio.no wrote:

Dear Thuy,

I’m not very familiar with the requirements in Sri Lanka, but I have a few

general comments. First, the categories and combinations should be used

when we want to aggregate them into a data element that is a natural total

of these categories. For stock, this is usually not the case, as we do not

want to add start balance, received, issued, and monthly requirement (in

this case).

About the total meaning of categories and categories options. I got the

lesson from my mistake in Vietnam. So I didn’t want to repeat again by

explanation people here. But again because of the instant benefit of

category data elements such as the defaul entry form will generate

automatically with good form which DHIS provided. And the shorting of

creating data elements,… So the person who do this project decided to use

categories for this report as well as other reports for equipments like

beds, tables,… I knew it is wrong for the meaning of categories which

developers in DHIS wish to use. But I don’t know serious reason for defense

on this. That’s why I consult you to know what will happen in the future

when data base become huge if we use category options like this for data

elements? Is it affecting to retrieving information later?

Hi Thuy,

I personally think one has to weight these things against each other.

I understand very well the desire to have nice autogenerated forms,

and I don’t really see the big problem with using categories this way

AS LONG AS one bears in mind that the total will not work. I think the

major downside to doing it like this is that Pivot tables will not

work well on these dataelements, since the whole point of pivot tables

is to easily sum up - and if some of the sums are meaningless, that

restricts the usefulness of the pivot tables.

It would be nice if it were possible to easily generate good looking

forms without violating the semantics of the aggregation model, though

I suppose that would require a decoupling of the form section

generating machinery from the data element model. One would then be

able to assign categorycombos to a section, but also group data

elements in sections external to the disaggregation model.

Knut


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

there seem to be 3 primary motivations for an implementor to use
categories
(i) it can make auto-generated forms do what you want
(ii) it reduces the number of dataelements you have to design
(iii) it provides an axis for analysis

In the best of cases these three conspire together to produce a good
result. eg datavalues which are collected disaggregated by sex.

In other cases the benefits of (i) are so compelling that the fact
that (iii) is not consistent is not considered. I've seen a few
proposed solutions to this (I think most recently a setting which
indicates whether a category is a "summing" category or not). Not
sure if I'm too happy with any of them, but one observation is that in
almost all cases I've seen this occur, it is related to
stock/inventory. This might just be a coincidence but sure looks like
a pattern to me. perhaps there might be a point in recognizing the
special case of inventory and make a small inventory module rather
than handling through "standard" data entry.

In Kenya it is actually the human resources form that is the problem. They
repeat 10 columns (that do not add up) over about 40-50 different cadres, so
many data elements.

OK. I guess HR, like inventory, proceeds with its own logic which is
hard to completely capture in a simple data collection model.

I do also find myself agreeing with you that in a situation like this
and given current concrete reality, it should be better practice to
group data collection by category rather than to proliferate so many
dataelement names. But the consequences still bother me. Will think
more later ...

Cheers
Bob

···

On 7 December 2010 10:17, Ola Hodne Titlestad <olati@ifi.uio.no> wrote:

On 7 December 2010 10:41, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

But I agree that stock forms are the most common one and that we should look
into better support for logistics functionality, at least the simpler
inventory stuff that is close to our model anyway.
I think we have put "use of calculated expressions in custom data entry" on
the roadmap somewhere. These will then provide a tools for adding more
complex calculations that are needed in the form. Of course if we limit this
functionality to the custom forms, which seems easier and less complex, then
we can't use the auto-generated forms anyway.....
Ola

Looking at the 4 categoryoptions there is an opening balance, amount
issued, amount received and avg monthly requirement in each case. As
well as stock reorder amounts etc associated with each dataelement.
Thuy seems to have done a good job in removing some of the extra
calculated values. Though I am not sure about average monthly
requirement. is that really an observation or is it calculated
somehow? And how do we persist things like the min/max amounts etc.
Anyway there seems to be a particular and repeated logic which drives
these stock/inventory dataelements. A stock/inventory module could
provide form layout based on that logic rather than on categorycombo.
As well as some extra data attributes for inventory related stuff
which would not be what we would term datelement.

From analysis perspective the fewer the categories the better, reusing
categories is good and categories which don't add up are bad as they
create confusion and complication at the output end.

From UI perspective, unless we can provide an alternative simple way
of achieving the simple tabular layout, users will continue to (ab)use
the categories for this. The labour saving is really just too much.

Sorry Thuy this is a bit of a distrasction from your initial question,
which I see Johan is addressing :slight_smile:

Cheers
Bob

On 7 December 2010 08:23, Jason Pickering <jason.p.pickering@gmail.com> >> wrote:
> This has got me thinking once again what a category/combo/option
> actually is and how the current implementation makes too many
> assumptions, like that categories should add up to a total.
>
> I would suggest we continue thinking about it in background document
> I created a while back..
>
>
> Categories concept paper.doc - Google Docs
>
>
> On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <knutst@gmail.com> wrote:
>> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen >> >> <thuy.hispvietnam@gmail.com> wrote:
>>> Dear Johan,
>>> Thank you for your suggestions. Please scroll down to see my mail
>>>
>>>
>>>
>>> On Tue, Dec 7, 2010 at 1:59 AM, <johansa@ifi.uio.no> wrote:
>>>>
>>>> Dear Thuy,
>>>>
>>>> I'm not very familiar with the requirements in Sri Lanka, but I have
>>>> a few
>>>> general comments. First, the categories and combinations should be
>>>> used
>>>> when we want to aggregate them into a data element that is a natural
>>>> total
>>>> of these categories. For stock, this is usually not the case, as we
>>>> do not
>>>> want to add start balance, received, issued, and monthly requirement
>>>> (in
>>>> this case).
>>>
>>> About the total meaning of categories and categories options. I got
>>> the
>>> lesson from my mistake in Vietnam. So I didn't want to repeat again by
>>> explanation people here. But again because of the instant benefit of
>>> category data elements such as the defaul entry form will generate
>>> automatically with good form which DHIS provided. And the shorting of
>>> creating data elements,... So the person who do this project decided
>>> to use
>>> categories for this report as well as other reports for equipments
>>> like
>>> beds, tables,... I knew it is wrong for the meaning of categories
>>> which
>>> developers in DHIS wish to use. But I don't know serious reason for
>>> defense
>>> on this. That's why I consult you to know what will happen in the
>>> future
>>> when data base become huge if we use category options like this for
>>> data
>>> elements? Is it affecting to retrieving information later?
>>
>> Hi Thuy,
>>
>> I personally think one has to weight these things against each other.
>> I understand very well the desire to have nice autogenerated forms,
>> and I don't really see the big problem with using categories this way
>> AS LONG AS one bears in mind that the total will not work. I think the
>> major downside to doing it like this is that Pivot tables will not
>> work well on these dataelements, since the whole point of pivot tables
>> is to easily sum up - and if some of the sums are meaningless, that
>> restricts the usefulness of the pivot tables.
>>
>> It would be nice if it were possible to easily generate good looking
>> forms without violating the semantics of the aggregation model, though
>> I suppose that would require a decoupling of the form section
>> generating machinery from the data element model. One would then be
>> able to assign categorycombos to a section, but also group data
>> elements in sections external to the disaggregation model.
>>
>> Knut
>>
>> _______________________________________________
>> Mailing list: DHIS 2 developers in Launchpad
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : DHIS 2 developers in Launchpad
>> More help : ListHelp - Launchpad Help
>>
>
>
>
> --
> Jason P. Pickering
> email: jason.p.pickering@gmail.com
> tel:+260968395190
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help
>

Several people have asked for the link to the Google doc, and I have
added them to the list of editors. I also changed the permissions to
allow anyone to read it. These are some random thoughts I have had
about the whole categories/combos/options. Your mileage may vary.

I have some more thoughts which I will add when I get a chance, after
this email, but feel free to add your thoughts as well to the doc.
Once we reach some consensus, if ever, perhaps this can evolve into a
more specific blueprint.

Here is the link...

···

On 12/7/10, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

On 7 December 2010 10:17, Ola Hodne Titlestad <olati@ifi.uio.no> wrote:

On 7 December 2010 10:41, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

there seem to be 3 primary motivations for an implementor to use
categories
(i) it can make auto-generated forms do what you want
(ii) it reduces the number of dataelements you have to design
(iii) it provides an axis for analysis

In the best of cases these three conspire together to produce a good
result. eg datavalues which are collected disaggregated by sex.

In other cases the benefits of (i) are so compelling that the fact
that (iii) is not consistent is not considered. I've seen a few
proposed solutions to this (I think most recently a setting which
indicates whether a category is a "summing" category or not). Not
sure if I'm too happy with any of them, but one observation is that in
almost all cases I've seen this occur, it is related to
stock/inventory. This might just be a coincidence but sure looks like
a pattern to me. perhaps there might be a point in recognizing the
special case of inventory and make a small inventory module rather
than handling through "standard" data entry.

In Kenya it is actually the human resources form that is the problem. They
repeat 10 columns (that do not add up) over about 40-50 different cadres,
so
many data elements.

OK. I guess HR, like inventory, proceeds with its own logic which is
hard to completely capture in a simple data collection model.

I do also find myself agreeing with you that in a situation like this
and given current concrete reality, it should be better practice to
group data collection by category rather than to proliferate so many
dataelement names. But the consequences still bother me. Will think
more later ...

Cheers
Bob

But I agree that stock forms are the most common one and that we should
look
into better support for logistics functionality, at least the simpler
inventory stuff that is close to our model anyway.
I think we have put "use of calculated expressions in custom data entry"
on
the roadmap somewhere. These will then provide a tools for adding more
complex calculations that are needed in the form. Of course if we limit
this
functionality to the custom forms, which seems easier and less complex,
then
we can't use the auto-generated forms anyway.....
Ola

Looking at the 4 categoryoptions there is an opening balance, amount
issued, amount received and avg monthly requirement in each case. As
well as stock reorder amounts etc associated with each dataelement.
Thuy seems to have done a good job in removing some of the extra
calculated values. Though I am not sure about average monthly
requirement. is that really an observation or is it calculated
somehow? And how do we persist things like the min/max amounts etc.
Anyway there seems to be a particular and repeated logic which drives
these stock/inventory dataelements. A stock/inventory module could
provide form layout based on that logic rather than on categorycombo.
As well as some extra data attributes for inventory related stuff
which would not be what we would term datelement.

From analysis perspective the fewer the categories the better, reusing
categories is good and categories which don't add up are bad as they
create confusion and complication at the output end.

From UI perspective, unless we can provide an alternative simple way
of achieving the simple tabular layout, users will continue to (ab)use
the categories for this. The labour saving is really just too much.

Sorry Thuy this is a bit of a distrasction from your initial question,
which I see Johan is addressing :slight_smile:

Cheers
Bob

On 7 December 2010 08:23, Jason Pickering <jason.p.pickering@gmail.com> >>> wrote:
> This has got me thinking once again what a category/combo/option
> actually is and how the current implementation makes too many
> assumptions, like that categories should add up to a total.
>
> I would suggest we continue thinking about it in background document
> I created a while back..
>
>
> Categories concept paper.doc - Google Docs
>
>
> On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <knutst@gmail.com> wrote:
>> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen >>> >> <thuy.hispvietnam@gmail.com> wrote:
>>> Dear Johan,
>>> Thank you for your suggestions. Please scroll down to see my mail
>>>
>>>
>>>
>>> On Tue, Dec 7, 2010 at 1:59 AM, <johansa@ifi.uio.no> wrote:
>>>>
>>>> Dear Thuy,
>>>>
>>>> I'm not very familiar with the requirements in Sri Lanka, but I have
>>>> a few
>>>> general comments. First, the categories and combinations should be
>>>> used
>>>> when we want to aggregate them into a data element that is a natural
>>>> total
>>>> of these categories. For stock, this is usually not the case, as we
>>>> do not
>>>> want to add start balance, received, issued, and monthly requirement
>>>> (in
>>>> this case).
>>>
>>> About the total meaning of categories and categories options. I got
>>> the
>>> lesson from my mistake in Vietnam. So I didn't want to repeat again
>>> by
>>> explanation people here. But again because of the instant benefit of
>>> category data elements such as the defaul entry form will generate
>>> automatically with good form which DHIS provided. And the shorting of
>>> creating data elements,... So the person who do this project decided
>>> to use
>>> categories for this report as well as other reports for equipments
>>> like
>>> beds, tables,... I knew it is wrong for the meaning of categories
>>> which
>>> developers in DHIS wish to use. But I don't know serious reason for
>>> defense
>>> on this. That's why I consult you to know what will happen in the
>>> future
>>> when data base become huge if we use category options like this for
>>> data
>>> elements? Is it affecting to retrieving information later?
>>
>> Hi Thuy,
>>
>> I personally think one has to weight these things against each other.
>> I understand very well the desire to have nice autogenerated forms,
>> and I don't really see the big problem with using categories this way
>> AS LONG AS one bears in mind that the total will not work. I think the
>> major downside to doing it like this is that Pivot tables will not
>> work well on these dataelements, since the whole point of pivot tables
>> is to easily sum up - and if some of the sums are meaningless, that
>> restricts the usefulness of the pivot tables.
>>
>> It would be nice if it were possible to easily generate good looking
>> forms without violating the semantics of the aggregation model, though
>> I suppose that would require a decoupling of the form section
>> generating machinery from the data element model. One would then be
>> able to assign categorycombos to a section, but also group data
>> elements in sections external to the disaggregation model.
>>
>> Knut
>>
>> _______________________________________________
>> Mailing list: DHIS 2 developers in Launchpad
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : DHIS 2 developers in Launchpad
>> More help : ListHelp - Launchpad Help
>>
>
>
>
> --
> Jason P. Pickering
> email: jason.p.pickering@gmail.com
> tel:+260968395190
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help
>

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