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@gmail.com 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@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.hispvietnam@gmail.com
Cell phone: +84 97 324 1542
================================
On Mon, Jan 25, 2010 at 6:37 PM, Abyot Gizaw abyota@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
- creating the attribute group … with all the parameters it is required to have - including assigning/reassigning attribute(s)
- 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@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.
- Create groups property for patient and request users add it in new patient GUI
- Create other function named Add Groups for each in list of patients.
- 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@gmail.com
Cell phone: +84 97 324 1542
On Thu, Jan 21, 2010 at 8:58 PM, Cong Duong Dinh duong_dinhcong@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. Get it now
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@gmail.com
To: abyota@gmail.com
CC: duong_dinhcong@hotmail.com; tranthanhtri84@gmail.com; sam.hispvietnam@gmail.com; thuy.hispvietnam@gmail.com; hieu.hispvietnam@gmail.com; catakim@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.hispvietnam@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.
- 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
- 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
- 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,…
- 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.
- 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.
- 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
- 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@gmail.com
hei all,
How’s it going?
Thanks for the reply!
2010/1/20 Jørn Braa jornbraa@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:
-
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…???
-
I see the integration part for Program with DAEL… but don’t know how to link/integrate with the current/existing DAELs of DHIS2?
-
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@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
kavo@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
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®.
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
–
Viet Nguyen