dhis2-devs team mailing list archive

[Viet Nguyen <phamquocviet@xxxxxxxxx>]

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