Hi Abyot, I take a look the model.
Do you want to use attribute group for listing attributes according to group in input-attribute GUI and we don't create a relationship between patient and attribute group ?? If we do that, end-user have to choose groups many times to enter all attribute for patient. For example, we have 3 groups for Mother Form: 1. Resident address group : phonenumber, housenumber, street 2. Temp. address group : phonenumber, housenumber , street 3. Mother group : pre-pergnancy 4. Child group : weight, aprar 1, apgar 2, malformation. When end-users input attributes for Mother Object, they choose 3 groups: Resident group, temp. group and Mother group. Why don't we assign groups for patient before. How do you have any suggestion for this problem ? ================================ Châu Thu Trân HISP Viet Nam Email: tran.hispviet...@gmail.com Cell phone: +84 97 324 1542 ================================ On Wed, Jan 27, 2010 at 2:10 PM, Chau Thu Tran <tran.hispviet...@gmail.com>wrote: > Hi Abyot, > > I also think about that. I'm tryng to remove attributes. > > ================================ > Châu Thu Trân > HISP Viet Nam > Email: tran.hispviet...@gmail.com > Cell phone: +84 97 324 1542 > ================================ > > > On Wed, Jan 27, 2010 at 1:52 PM, Abyot Gizaw <aby...@gmail.com> wrote: > >> Hi Tran, >> >> Have seen your changes.... great job! >> >> But a small comment ... a patient has both attribute and attributeGroup >> assigned to it. I think one of them should be removed :) >> >> >> On Tue, Jan 26, 2010 at 6:37 AM, Chau Thu Tran < >> tran.hispviet...@gmail.com> 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.hispviet...@gmail.com >>> Cell phone: +84 97 324 1542 >>> ================================ >>> >>> >>> On Mon, Jan 25, 2010 at 6:37 PM, Abyot Gizaw <aby...@gmail.com> 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.hispviet...@gmail.com> 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.hispviet...@gmail.com >>>>> Cell phone: +84 97 324 1542 >>>>> ================================ >>>>> >>>>> >>>>> On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh < >>>>> duong_dinhc...@hotmail.com> 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.hispviet...@gmail.com >>>>>> To: aby...@gmail.com >>>>>> CC: duong_dinhc...@hotmail.com; tranthanhtr...@gmail.com; >>>>>> sam.hispviet...@gmail.com; thuy.hispviet...@gmail.com; >>>>>> hieu.hispviet...@gmail.com; cata...@gmail.com >>>>>> >>>>>> >>>>>> 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.hispviet...@gmail.com> >>>>>> >>>>>> 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 <cata...@gmail.com> >>>>>> >>>>>> hei all, >>>>>> >>>>>> How's it going? >>>>>> >>>>>> Thanks for the reply! >>>>>> >>>>>> 2010/1/20 Jørn Braa <jornb...@gmail.com> >>>>>> >>>>>> 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 <jornb...@gmail.com>: >>>>>> > 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 >>>>>> k...@ifi.uio.no >>>>>> 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@lists.launchpad.net >>>>>> 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 Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp