dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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@xxxxxxxxxx> 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@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 :
>>>>
>>>> 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: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> 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
>
>