dhis2-devs team mailing list archive

[johansa@xxxxxxxxxx]

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@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
>>
>>
>
> _______________________________________________
> 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
>