dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

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 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<http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Vetlandsvn.+95B,+0685+Oslo,+Norway>
----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps
link<http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Vetlandsvn.+95B,+0685+Oslo,+Norway>


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

> hello,
>
> On Thu, Nov 4, 2010 at 1:47 PM, Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>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 ;)
>
>
>
>> I need more your explainations
>>
>>
> These above are just my own understanding/analysis, anyone from HISP can
> help out more :) with comments!
>
>
>
>>
>> Thuy
>> ---------- Forwarded message ----------
>> From: Kim-Anh Vo <catakim@xxxxxxxxx>
>> Date: Thu, Nov 4, 2010 at 10:31 AM
>> Subject: Re: New requirement from Sri Lanka
>> To: Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>
>>
>>
>> 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 :)
>>
>> 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@xxxxxxxxx>wrote:
>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx>
>>>  Date: Tue, Nov 2, 2010 at 3:44 AM
>>> Subject: Re: New requirement from Sri Lanka
>>> To: John lewis <johnlewis.hisp@xxxxxxxxx>
>>>
>>>
>>> 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.
>>>
>>>
>>> 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: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>