dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

Hi,

I think it is better not to mix attributes with the type of service an
individual is getting - those given to children, mothers, and others ... can
easily be captured through dataelements of programstages and programs.

An individual has for sure name, gender and date of birth and these for me
are mandatory attributes of an individual. That is why they are in the
immediate screen of individual registration. It is also obvious that these
are not the only attributes an individual can have ... we can have many more
and we don't know how many and what sort of - that is why we have a
functionality to let users define their own attributes. Out of these newly
defined attributes some could be mandatory some not .... this will ask for
an additional parameter of "isMandatory" or something like that for
attributes. Then we can put those mandatory attributes in the individual
registration screen.

Another point I would like to make is that - attributes are assigned to
individuals when we put values for them. So we are not asking users to make
extra efforts for assigning attributes. And Tran, I think it is better if
you could keep the attributes and remove attributeGroups from patients. If
we do it the attributeGroups way then we will be in trouble because we don't
know in which group mandatory attributes will be. Above all, we can't keep
all the mandatory attributes in one group - if we do so then grouping of
attributes will not make any sense because we will only have two groups -
mandatory and non-mandatory.

But the attribute group is very important to manage attributes especially in
display - that is also what Tran mentioned us last time. You want only
attributes belonging to mothers to be displayed in the report? So when
displaying attributes in reports and dataEntry screens we display them under
their group heading.

Tran... to give you a practical example see how the dataElements,
dataElementGroups and dataSets are organised. You create dataElements and
assign them to dataElementGroups. Then to assign dataElements to dataSets
you identify the dataElement you want from the list of all available
dataElements or you browse through the dataElementGroups - but you are not
assigning dataElementGroups to dataSets.

And Hieu, yes I know the relationship between dataelements and
dataElementGroups (many-to-many) is not the same as the relationship I am
suggesting for attributes and attributeGroups (one-to-many). That is what I
mean by follow the same step we have there but make sure you restrict
attribute to belong only to one attributeGroup. What I am trying to say is
that ....try to organize attributes, attributeGroups and patient assignments
the way we have it in dataElements, dataElementGroups and dataSets.

So,... no question that mandatory attributes are filled the moment we
register an individual. Then for the rest of the attributes we can use the
attributeValue screen. From the list of patients, you select attribute
management link then you be provided with a screen where you can put values
for the attributes. We can modify this screen so that attributes can be
displayed according to their grouping - may be using drop down list of
attributeGroups. You select an attributeGroup, attributes will be displayed
and you put on values - at the same time assigning attributes to patients.
You select another attributeGroup, put values and it goes on....


Thank you
Abyot.


On Wed, Jan 27, 2010 at 8:45 AM, Viet Nguyen <phamquocviet@xxxxxxxxx> wrote:

> Hi,
>
> In India , we have a requirement that all the attributes should be display
> on the add patient form. A patient will be saved only when all the mandatory
> fields ( includes all the attributes )  have value. It 's not really
> user-friendly when user have to reach 2 forms when they want to save a
> patient...thinking of the number of patients that a data entry person has to
> deal with in one day...
>
> And also this is because of checking duplication. Some mandatory attribute
> can be used for checking if a patient is existing or not .
>
> A mandatory field will be added to the attribute table. We will decide an
> attribute is mandatory or not when creating that attribute.
>
> About the attribute group, at first I thought that  a group would contains
> all the attributes that belong to a specific patient type. IE : user would ,
> at first , choose one of those types : children < 1 year, children < 5 year,
> male, female ... . Then all the attributes would appears.  The mandatory
> field would then be added to the association table between attribute and
> attribute group.
>
> .... Well I can say, I was confused about this attribute group, because in
> that case, it sounds something like a Patient Type table :( ......  The best
> case I can think of is  user does not have to choose a group, because all
> the groups are differ from each other base on the gender and age... so maybe
> we can add those  values to the attribute groups table, then after user
> enter values for gender and ages, we can get the list of attributes base on
> that info then ajax-load them to the form.
>
> This sounds complicated in the background.... but  it should work well on
> front-end interface...
>
> Any advice ?
>
>
> On Tue, Jan 26, 2010 at 11:07 AM, Chau Thu Tran <
> tran.hispvietnam@xxxxxxxxx> wrote:
>
>> Hi Abyot and Others,
>>
>> I test a case to assign attribute groups to patients. I created new
>> function named *Assign Attribute Groups* for each in list of patients. It
>> means after to create a patient, end-users have to choose the function to
>> assign attribute groups for the patients. The groups in here is option, not
>> madatory group. And attributes of madatory groups will show when end-users
>> enter *patient-attribute-value.*
>>
>> How do you think about this ?
>>
>> I send the patch.diff file to you. Please find enclosed the attached file to
>> see the report.
>>
>> ================================
>> Châu Thu Trân
>> HISP Viet Nam
>> Email: tran.hispvietnam@xxxxxxxxx
>> Cell phone: +84 97 324 1542
>> ================================
>>
>>
>> On Mon, Jan 25, 2010 at 6:37 PM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>>
>>> Hi Tran,
>>>
>>> Great that you already started working on the attribute group ...... and
>>> treating the whole thing as a two step process will be nice
>>>
>>>    1. creating  the attribute group .... with all the parameters it is
>>>    required to have - including assigning/reassigning attribute(s)
>>>    2. assigning attribute(s) to patients
>>>
>>> *Creating attribute group*
>>>
>>> For step 1 you can follow the approach we have in DataElements and
>>> DataElementGroups. At the same I would suggest for a restriction of putting
>>> an attribute only in one group - otherwise it will be ugly down the road.
>>> Because, for example in your case of permanent and temporary address
>>>
>>> Temporary Address Group
>>>
>>>    - street
>>>    - village
>>>    - province
>>>    - ...
>>>    - ..
>>>    - phone
>>>
>>> then Permanent Address Group arrangement of the same attributes
>>>
>>>    - street
>>>    - village
>>>    - province
>>>    - ...
>>>    - ..
>>>    - phone
>>>
>>> will create a problem in fetching the values ... otherwise we need to
>>> also store attribute group id when persisting attribute values.....I prefer
>>> to append something like "temp" and create slightly different attributes
>>> than persisting attribute group id when storing attribute values - I don't
>>> know others can comment on this and come up with a better suggestion.
>>>
>>> *Assigning attributes to patients*
>>>
>>> We need to make a little adjustment for this one. Because if we plan to
>>> enforce users put value, the moment they register a patient, for some
>>> selected attributes, then we need to bring these mandatory attributes to the
>>> screen where we are entering patient parameters. So this implies two changes
>>> then: the first one adding additional Boolean parameter with a value of
>>> yes/no for attributes and the second one, at the bottom of the patient
>>> registration screen (under name, sex, age), we need to list these mandatory
>>> attributes and enforce users put values while registering patients. But for
>>> this to work, pray that mandatory attributes are valid for all individuals
>>> we will be registering. Other, if we have a scenario of mandatory for males,
>>> females, mothers, children,.... then we are in trouble of slipping into
>>> multiple registration forms varied for males, females, mothers, babies
>>> ------ what do you people think, especially those of you who have had the
>>> experience of the field?
>>>
>>>
>>> Tran, is this any thing helpful for the question you asked? I know you
>>> asked me for specific places to put the functionality you are making ... but
>>> I thought raising these issues will also guide you.
>>>
>>> Thank you
>>>  Abyot.
>>>
>>>
>>>
>>> On Mon, Jan 25, 2010 at 10:36 AM, Chau Thu Tran <
>>> tran.hispvietnam@xxxxxxxxx> wrote:
>>>
>>>> Hi Abyot and others,
>>>>
>>>> I created the function of attribute group management. And now, I don't
>>>> know where is suitable place to add that function. I thought to put on one
>>>> of three places as below, but i am not sure.
>>>> 1. Create groups property for patient and request users add it in new
>>>> patient GUI
>>>> 2. Create other function named Add Groups for each in list of patients.
>>>> 3. Create combox to load all of groups existing in the system and
>>>> end-user has to choose each group to enter attribute.
>>>>
>>>> What is your suggestion?
>>>>
>>>> ================================
>>>> Châu Thu Trân
>>>> HISP Viet Nam
>>>> Email: tran.hispvietnam@xxxxxxxxx
>>>> Cell phone: +84 97 324 1542
>>>> ================================
>>>>
>>>>
>>>> On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh <
>>>> duong_dinhcong@xxxxxxxxxxx> wrote:
>>>>
>>>>>  OK Tran that's good,
>>>>> Try to go ahead......
>>>>>
>>>>> Duong Dinh Cong MD. PhD
>>>>> Community Health Department
>>>>> Medical School Pham Ngoc Thach
>>>>> Home 22 Ho Huan Nghiep Q1 HCM City
>>>>> 0903359924
>>>>>
>>>>> --- @ WiseStamp Signature<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>.
>>>>> Get it now<http://my.wisestamp.com/link?u=6zk6hnnyzjswmm3g&site=www.wisestamp.com/email-install>
>>>>>
>>>>>
>>>>> Duong Dinh Cong CUF/UTC 520 Ng Tri Phuong QX HCM-City Vietnam Tel 84 8
>>>>> 8631383 Fax 84 8 650025
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> Date: Thu, 21 Jan 2010 17:41:39 +0700
>>>>>
>>>>> Subject: Re: [Dhis2-devs] Greetings + new DHIS patient module
>>>>> From: tran.hispvietnam@xxxxxxxxx
>>>>> To: abyota@xxxxxxxxx
>>>>> CC: duong_dinhcong@xxxxxxxxxxx; tranthanhtri84@xxxxxxxxx;
>>>>> sam.hispvietnam@xxxxxxxxx; thuy.hispvietnam@xxxxxxxxx;
>>>>> hieu.hispvietnam@xxxxxxxxx; catakim@xxxxxxxxx
>>>>>
>>>>>
>>>>> Hi Abyot,
>>>>>
>>>>> The Mother Form system has two objects, mother and child. There are
>>>>> somes attributes belonging to mother that does not belong to child and vice
>>>>> versa. For example, the atributes of mother are housenumber, street and pre-prefnacy
>>>>> (***). And the attributes of child are information when to be born,
>>>>> include apgar 1, apgar 5, weight and malformation
>>>>>
>>>>> When I build attributes for the object in your module, I have to define
>>>>> all of  the attributes of the mother and child. So, when to create a new
>>>>> object and input attributes for it, all of the attributes of both objects
>>>>> are displayed in the form. How do you think if we have a function to group
>>>>> attributes of each.
>>>>>
>>>>> Now, I created attributes, dataelements, relationship and a program for
>>>>> Mother Form, as follows:
>>>>>  - Attribute : pre-pegnacy, housenumber, street, weight, apgar 1, apgar
>>>>> 2, malformation.
>>>>>  - Relationship: is mother of / is child of
>>>>>  - Program : Mother Form with stages: Before to born, After to born and
>>>>> Result
>>>>>
>>>>> and try to enter some forms.
>>>>>
>>>>> However, I do not created  the realationship for mother and child
>>>>> objects (because when I choose the relationship to add,  the system reload
>>>>> the page without saving the selected objects to create relationship).
>>>>>
>>>>> When will we be able to start develop with you in this patient system ?
>>>>>
>>>>> ------
>>>>> *** pre-pregnacy : it has four digits.
>>>>>       - First: number of *unpremature-birth* children
>>>>>       - Second : number of *premature-birth* children
>>>>>       - Third:  number of *abortion*
>>>>> *      *- Forth: number of *alive *children
>>>>>       Example: a mother A has a unpremature-birth child
>>>>> --> pre-pregnacy is 1001
>>>>>
>>>>> 2010/1/21 Chau Thu Tran <tran.hispvietnam@xxxxxxxxx>
>>>>>
>>>>> Chào thầy và các bạn
>>>>>
>>>>> Em đã tạo các DEs của phiếu sanh để test thử module DHIS2 và phát hiện
>>>>> một số vấn đề (đã gửi mail và Abyot đã trả lời mail ).
>>>>>
>>>>> Em đang thảo luận với Abyot về các vấn đề khi áp dụng chương trình
>>>>> Patient cho Việt Nam. Sau khi đã rõ ràng về requirements ở Việt Nam, em sẽ
>>>>> thảo luận tiếp các việc phải làm cho module này.
>>>>>
>>>>>
>>>>> Great that you have started looking into the patient module of DHIS2.
>>>>> The advantage with this module is that it is part of DHIS2 - no installation
>>>>> of other system and also easy sharing of dataelements and orgunits defined
>>>>> under DHIS2.
>>>>>
>>>>> Below is a little clarification for some of the questions you raised.
>>>>>
>>>>>    1. *Issue with multiple address* - Address is a little tricky
>>>>>    concept, I believe. If treated with a single object, say for example
>>>>>    Address, and set of attributes then we will end up in a difficulty of
>>>>>    entertaining all the possible definitions an address is supposed to have.
>>>>>    For a global software like DHIS2 we need to treat the address concept as
>>>>>    open as possible there by allowing a flexibility for specific local
>>>>>    definitions of addresses. So how we treat address is then is using objects
>>>>>    PersonAttribute and PersonAttributeValue. Using PersonAttribute we can
>>>>>    create as many custom objects as possible - say for example StreetAddress
>>>>>    with a datavalue type of text, HouseNumber with a datavalue type of number
>>>>>    or text, PhoneNumber with number, ....... any custom object with datavalue
>>>>>    type of text/number/yes_no/date....... once we defined such custom objects,
>>>>>    we can latter put specific values through PersonAttributeValue. My
>>>>>    suggestion for your case will be to define the parameters of your temporary
>>>>>    and resident addresses as PersonAttributes and for each person attribute
>>>>>    create a person attribute value - then latter you can group these attributes
>>>>>    into "Temporary Address" and "Resident Address"........ of course we need to
>>>>>    first provide a functionality for grouping of person attributes
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    1. *Integration with DataElements* - Yes the patient module uses
>>>>>    dataelements defined under DHIS2. But to avoid confusion with the value
>>>>>    types and aggregation operation we have introduced an attribute called
>>>>>    domainType with a possible values of patient and aggregate for the time
>>>>>    being. The reason for this is for example in the patient module you might
>>>>>    only be interested in putting a yes or no value for a specific vaccine type,
>>>>>    but in the aggregate/DHIS you might only be interested in knowing for how
>>>>>    many babies this specific vaccine is given. So the bottom line is when
>>>>>    defining your dataelements specify for which domain you are creating them
>>>>>    --- then those with patient type will appear in the patient module and those
>>>>>    with aggregate type will appear in DHIS
>>>>>    2. *Health Program Stage* - this is to handle specific stages of a
>>>>>    health program - because you might have multiple encounters for a given
>>>>>    health program. For example in your case there will be a scenario where a
>>>>>    pregnant  woman will be treated for her first trimester, second trimester
>>>>>    and/or third trimester once she is in "ANC Program". This encounters in most
>>>>>    cases are mandatory, of course there will be dropouts in some cases, which a
>>>>>    pregnant woman should go through once she is in the "ANC Program". So when
>>>>>    creating a health program you can also define the specific stages of the
>>>>>    health program. Because you will be recording observations (collecting
>>>>>    values) during each of these specific stages, then you associate
>>>>>    dataelements with program stages not programs. To make it more general a
>>>>>    health program can have one or more program stages - like you observe a
>>>>>    patients cases once or multiple times. This approach works fine for ANC,
>>>>>    Immunization, TB, Malaria,....
>>>>>    3. *Date of Incidence* - Let's say you define a health program and
>>>>>    its stages as mentioned above. And a person comes for treatment, say for
>>>>>    example pregnant woman. Then the system should automatically generate visit
>>>>>    dates for the subsequent ANC visits - or program stages. But to generate
>>>>>    these visit schedules we need to ask the mother when is the first time she
>>>>>    got pregnant, or in the standard ANC term ??LMP Date??. The day she came for
>>>>>    treatment might not necessarily be the day she got pregnant, therefore for a
>>>>>    better treatment (by having appropriate visit dates) it will be nice if we
>>>>>    can get information about the date she got pregnant - that is what the Date
>>>>>    of Incidence is all about. The same logic also works for a TB patient for
>>>>>    example - the date the person came for treatment might not necessarily be
>>>>>    the date he/she got the disease --- so better to know the date of incidence.
>>>>>    4. *Custom Data Entry Form and Reports *- I think Viet has answered
>>>>>    this partly - as he is working on custom data entry screens. What we have
>>>>>    right now is more of a generic framework - input screens, reports
>>>>>    layouts,... are something which we need to further work for specific
>>>>>    implementations.
>>>>>    5. *Relationships* - Yes we can define any relationship types and
>>>>>    link individuals through these relationship types by creating specific
>>>>>    relationships.And we have this feature currently. What is missing is where
>>>>>    to specifically use these relationships, and I think this again depends on
>>>>>    specific implementations. I think of displaying relationship types in
>>>>>    reports and dataentry screens
>>>>>    6. *Registering a newly born baby *- This I would say is a
>>>>>    limitation of the system ... if you all think we can't assign a name for a
>>>>>    newly born baby before giving the baby any treatment we will be recording in
>>>>>    our system. My argument is any individual should first be registered in the
>>>>>    system before getting any treatment which we will be interested to record
>>>>>    data for - I could be wrong :)
>>>>>
>>>>> Hope I have addressed all your questions, but I couldn't understand one
>>>>> of your question shown below
>>>>>
>>>>> "The program have two objects, mother and child. They have some
>>>>> different properties. For example, mother has pre-pregnacy, child has apgar
>>>>> 1, apgar 5, malformation. We defines all of attributes for the
>>>>> objects. Because the system doesn't separates objects, so when to create a
>>>>> branch new object and input the attributes to it, the system show all of the
>>>>> attributes.How do you only show information for each object ?"
>>>>>
>>>>>
>>>>> Thank you
>>>>> Abyot.
>>>>>
>>>>>
>>>>> 2010/1/21 Kim Anh Thi Vo <catakim@xxxxxxxxx>
>>>>>
>>>>> hei all,
>>>>>
>>>>> How's it going?
>>>>>
>>>>> Thanks for the reply!
>>>>>
>>>>> 2010/1/20 Jørn Braa <jornbraa@xxxxxxxxx>
>>>>>
>>>>> Hi all,
>>>>> I suggest that
>>>>> Tran and Abyot work together on the DHIS patient module and that
>>>>>  we implement the patient module on the Mother and Child records in
>>>>> the centre  - and maybe other areas, and
>>>>>  use the concrete Vietnamese useers requirements and use situation to
>>>>> make the module much better.
>>>>>
>>>>>
>>>>> I checked out the DHIS patient module yesterday and it seems very open
>>>>> and good with design... simple, flexible and intergatable.
>>>>> Referring to the explaination by Jørn a few days ago, this module is
>>>>> clear to me :)
>>>>> And here is some questions I'd like to ask Abyot maybe about this
>>>>> module:
>>>>>
>>>>> 1. I created patients with all attributes + add some more ones (esp.
>>>>> the case in Vietnam... there are two address: "current address" and
>>>>> "permanent address", etc.) and then created some relationships (for example,
>>>>> for Mother and Child programs, that is "is a mother of", "is a child of"),
>>>>> but when going back to the patient lists to assign the relationship... this
>>>>> function couldn't be through... choosing the list of relationships but
>>>>> nothing HAPPEND next...???
>>>>> 2. I see the integration part for Program with DAEL... but don't know
>>>>> how to link/integrate with the current/existing DAELs of DHIS2?
>>>>> 3. About come concepts:
>>>>> 3.1. Incident? What is "Date of incident"?
>>>>> 3.2. What is "Health Program State"?
>>>>>
>>>>> Maybe further question relating to this... will come later :)
>>>>>
>>>>>
>>>>>
>>>>> Another issue; Quang is supposed to start work with us from March?
>>>>> Everybody agrees? and have you discussed with him?
>>>>>
>>>>>
>>>>> Remember mentioning this before and also talked to him... when I
>>>>> attended GNOME ASIA last year, and will contact with Quang for this after
>>>>> having the related information as I ask below!
>>>>> Jørn, will he work part-time for HISP Vietnam to support dev team?
>>>>> Are there any previous information about this connection/discussion
>>>>> with him (Quang) between HISP in general and HISP Vietnam in particular?
>>>>> If having, it'd be great you can give them to me... because I wanna
>>>>> know the status referring to this!
>>>>>
>>>>> Thank you!
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> jorn
>>>>>
>>>>>
>>>>> 2010/1/18 Jørn Braa <jornbraa@xxxxxxxxx>:
>>>>> > Dear all,
>>>>> > Hope everything is fine in the new year and that next (Vietnamese)
>>>>> > year will be even better for HISP.
>>>>> >
>>>>> > I write to update you on the new DHIS patient module. It is generic
>>>>> > and flexible and easy to set up. The use area is exactly what you are
>>>>> > working on with the Mother and Child records, and what we discussed
>>>>> in
>>>>> > Can Tho on for example vaccination (child) records.
>>>>> >
>>>>> > This patient (/client) module is
>>>>> > - registering names, birth dates, sex, adresses, IDs etc
>>>>> >
>>>>> > Persons may be (optional)
>>>>> > - grouped in households (or mother - children)
>>>>> >
>>>>> > Then for each patient/client
>>>>> > - each Encounter with the health services is registered
>>>>> >
>>>>> > Encounters are then linked to
>>>>> > - health facility (org unit), and
>>>>> > - Programs (e.g. RCH, EPI) which includes Schedules (e.g. sequence
>>>>> and
>>>>> > months after birth of required vaccines for an infant)
>>>>> >
>>>>> > Programs are then linked to
>>>>> > - data sets and data elements. These data elements are as DHIS data
>>>>> elements.
>>>>> >
>>>>> > INTEGRATION with aggregated HMIS data:
>>>>> > - data is aggregated by the end of each reporting period as according
>>>>> > to the reporting requirements
>>>>> >
>>>>> > For example the number of ANC first visits, or BCGs, Polio1s, Measle
>>>>> > vaccines etc.
>>>>> >
>>>>> > This system will be very well suited for the Mother and CHild - or
>>>>> > vaccination -  registers.
>>>>> >
>>>>> > The system is easy to design so it fits various patient data
>>>>> > requirements from health programs. It may be regarded as an extension
>>>>> > of the DHIS reporting system for statistical data.
>>>>> >
>>>>> > This system is now being tested in India. Here they are also using
>>>>> mobile
>>>>> > telephones - which we should also test in Vietnam.
>>>>> >
>>>>> > This was a very quick run-through. Lars and AByot can update on
>>>>> current "state
>>>>> > of the art", and other issues.
>>>>> >
>>>>> > As discussed before, I suggest that we start working on this DHIS
>>>>> > patient module system in Vietnam now.
>>>>> >
>>>>> > best regards,
>>>>> > jorn
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Best regards,
>>>>> Kim Anh Vo
>>>>>
>>>>> +84.906612246
>>>>> kavo@xxxxxxxxxx
>>>>> Coordinator of HISP(hisp.info) in Vietnam
>>>>> Master of Information Systems
>>>>> at the University of Oslo
>>>>> ------------------------------------
>>>>> join facebook at www.facebook.com join LinkedIn at www.linkedin.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> Windows Live Hotmail: Your friends can get your Facebook updates,
>>>>> right from Hotmail®.<http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009>
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Viet Nguyen
>
>