dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #08333
Re: New requirement from Sri Lanka
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
Follow ups
References