dhis2-devs team mailing list archive

[Chau Thu Tran <tran.hispvietnam@xxxxxxxxx>]

Hi Abyot,

I modify the source.

Please find enclosed the attached file to see the patch.diff file.

Best regards,

================================
Châu Thu Trân
HISP Viet Nam
Email: tran.hispvietnam@xxxxxxxxx
Cell phone: +84 97 324 1542
================================


On Wed, Jan 27, 2010 at 7:40 PM, Viet Nguyen <phamquocviet@xxxxxxxxx> wrote:

> Hi,
>
> Sorry for miss-understanding  the words...
>
> I meant there would be an attribute that is mandatory for Child, but not
> for other type of Person ( male, female, ... ). Still I can not think of any
> example, so.. never-mind it :)
>
> Thank you,
>
> On Wed, Jan 27, 2010 at 5:59 PM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>
>>
>>
>> On Wed, Jan 27, 2010 at 12:49 PM, Viet Nguyen <phamquocviet@xxxxxxxxx>wrote:
>>
>>>
>>> Hi,
>>>
>>> I got your point.
>>>
>>> Just two more questions :
>>>
>>>    1. Why dont we put the attribute groups things into the case
>>>    registration form ? is it better for user if they can enter all of the
>>>    information in just one place ? Or mabye, I have just thought of redirecting
>>>    user to the case attribute entry form after a case is successfully saved. We
>>>    could also display all information again in disabled text field on top of
>>>    the page, and below would be the attribute group things... what do you think
>>>    ?
>>>    2. What should we do if there is an attribute is mandatory to one
>>>    case , but not to others ..... ? Current, I can not think of any example
>>>    ...not sure that it would happen or not ...But this is the reason why I
>>>    thought of the case type ...
>>>
>>> I don't think we are in the same track  Viet :) *
>>
>> **It is better not to mix attributes with the type of service an
>> individual is getting.
>>
>> *Attributes are meant for extended description of an individual - name,
>> age, gender, dob, height, eyecolor, nationality, mobilephonenumber,
>> fixedphonenumber, emailAddress, alternateEmailAddress, tempHouseNumber,
>> perHouseNumber, curCity, curCountry, perCity, perCountry,.................
>>
>> But I don't think this is how you view attributes. You are relating cases
>> and attributes ... "an attribute is mandatory  to one case, but not to
>> others". This is a completely different approach.* *What do you mean by a
>> case? What is the difference between a case and a health program?
>>
>> If you are looking for an extended description of a "case" - then use
>> dataElements. Can you think of one example, at least one, which is a
>> mandatory attribute for one case but not for others?
>>
>> My understanding is that when you say "case" you are talking about -
>> immunization, ANC, PNC,.... which we modeled them as health programs. What
>> ever data you are collecting for a program (or in your terminology  "case")
>> is captured through dataElements - so there shouldn't be an attribute for a
>> "case". If you have an attribute which is mandatory to one "case" but not to
>> others --- then this for me is not an attribute instead a it is a
>> dataelement which should be put in programs/programstages .
>>
>>
>>>    1.
>>>
>>> Thank you,
>>>
>>>
>>> On Wed, Jan 27, 2010 at 2:55 PM, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Viet Nguyen
>>>
>>>
>>
>
>
> --
> Viet Nguyen
>
>

Attachment: patch.diff
Description: Binary data