dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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