Greetings + new DHIS patient module

Dear Tran, Thuy, Kim and others,

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
  2. 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
  3. 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,…
  4. 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.
  5. 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.
  6. 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
  7. 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 :slight_smile:
    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 :slight_smile:

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

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

Hi Tran,

Ok, now I got it :slight_smile:

You want to see only those attributes that you intened to fill - for example you don’t want to see attributes like apgarXXX when dealing with Mother; and also things related with pre-pregnancy when dealing with babies. Is that your quesion?

If so then we can solve this by implementing a new feature - Attribute Group - which I suggested in my earlier mail. If we have this feature we can think of groups like containing mandatory attributes and optional attributes. In the mandatory group we put all attributes we think will be common for all individuals - be it baby, mother, male or female,… Then we can think of other groups like “Attributes for Mothers”, “Attributes for Babies”,… then everytime you register an individual you should also specify the attributes you want to record data for by choosing attribute group(s) and only those attributes associated will be shown for when you try to record data. By default all individuals need to have the mandatory attribute group.

So, this I think is a perfect opportunity for you to start working on the patient module. Checkout the code, see the internals of the patient module and start working in implementing the new feature suggested - Attribute Group. Then we will move to other issues?

You can always ask for any question you will have … but make sure you send your mails to the devs list so that others can also comment.

Abyot.

···

2010/1/21 Chau Thu Tran tran.hispvietnam@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.

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

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

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

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 ?

Hi Tran,

Ready to work in the patient module? Last time I was telling you to develop grouping functionality for PatientAttributes.

Abyot.

···

2010/1/21 Chau Thu Tran tran.hispvietnam@gmail.com


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

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

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

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

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

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

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

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

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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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

Dear Abyota**,**

I’m trying to follow your working on Patient module so that I’ve got some questions wanna ask you like this:
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.

You suggested that the attribute group and attributes which have a relationship as one to many, didn’t you? But the approach in Dataelement management with the relationship is many to many.

Btw, you said also that “otherwise we need to also store attribute group id when persisting attribute values” but its seemly opposite to “I prefer to append something like “temp” and create slightly different attributes than persisting attribute group id when storing attribute values”.

Or I’m misunderstanding your idea?

On the other hand, Can you please explaining to me more about PatientIdentifier and PatientIdentifierType. What are they used for ?

Thanks !

···


Hieu.HISPVietnam
Good Health !

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.

patch.diff (252 KB)

···

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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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

Hi Abyot,

I also think about that. I’m tryng to remove attributes.

···

================================
Châu Thu Trân
HISP Viet Nam
Email: tran.hispvietnam@gmail.com

Cell phone: +84 97 324 1542

On Wed, Jan 27, 2010 at 1:52 PM, Abyot Gizaw abyota@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 :slight_smile:

On Tue, Jan 26, 2010 at 6:37 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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

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.hispvietnam@gmail.com
Cell phone: +84 97 324 1542

================================

On Wed, Jan 27, 2010 at 2:10 PM, Chau Thu Tran tran.hispvietnam@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.hispvietnam@gmail.com

Cell phone: +84 97 324 1542

On Wed, Jan 27, 2010 at 1:52 PM, Abyot Gizaw abyota@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 :slight_smile:

On Tue, Jan 26, 2010 at 6:37 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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

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 :frowning: … 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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

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 :frowning: … 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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

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 …
    Thank you,
···

On Wed, Jan 27, 2010 at 2:55 PM, Abyot Gizaw abyota@gmail.com 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@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 :frowning: … 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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


Viet Nguyen

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 :slight_smile: **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 .

···

On Wed, Jan 27, 2010 at 12:49 PM, Viet Nguyen phamquocviet@gmail.com wrote:

Thank you,

On Wed, Jan 27, 2010 at 2:55 PM, Abyot Gizaw abyota@gmail.com 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@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 :frowning: … 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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


Viet Nguyen

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

Thank you,

···

On Wed, Jan 27, 2010 at 5:59 PM, Abyot Gizaw abyota@gmail.com wrote:

On Wed, Jan 27, 2010 at 12:49 PM, Viet Nguyen phamquocviet@gmail.com 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 :slight_smile: **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 .

Thank you,

On Wed, Jan 27, 2010 at 2:55 PM, Abyot Gizaw abyota@gmail.com 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@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 :frowning: … 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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


Viet Nguyen


Viet Nguyen

Hi Abyot,

I modify the source.

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

Best regards,

patch.diff (252 KB)

···

================================

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

On Wed, Jan 27, 2010 at 7:40 PM, Viet Nguyen phamquocviet@gmail.com wrote:

Hi,

Sorry for miss-understanding the words…

I meant there would be an attribute that is mandatory for Child, but not for other type of Person ( male, female, … ). Still I can not think of any example, so… never-mind it :slight_smile:

Thank you,

On Wed, Jan 27, 2010 at 5:59 PM, Abyot Gizaw abyota@gmail.com wrote:

On Wed, Jan 27, 2010 at 12:49 PM, Viet Nguyen phamquocviet@gmail.com 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 :slight_smile: **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 .

Thank you,

On Wed, Jan 27, 2010 at 2:55 PM, Abyot Gizaw abyota@gmail.com 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@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 :frowning: … 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

  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@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
  1. Create other function named Add Groups for each in list of patients.
  1. 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.

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

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

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


Viet Nguyen


Viet Nguyen

Nice work Tran…

···

On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I modify the source.

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

Best regards,

Hi Abyot,

I assigned mandatory attributes under the patient registration screen.

Please find enclosed the attached file to see patch file.

Best regards,

patch.diff (76.3 KB)

···

================================
Châu Thu Trân

HISP Viet Nam
Email: tran.hispvietnam@gmail.com
Cell phone: +84 97 324 1542

2010/1/29 Lars Helge Øverland larshelge@gmail.com

On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I modify the source.

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

Best regards,

Nice work Tran…

Hi,

Here are things that I’ve changed for patient - branch

  • Add Date of Enrollment Description , Date of Incident Description for Program. This is because those description is differ from each program, when user enroll to a program, we need to show them the descriptions.
  • Move blood group to Patient table.
  • Merge Patient Attribute Group from trunk.
  • Add Patient Attribute Option . This is for any attribute that can have predefined value.
  • Bring all attribute groups to patient registration screen.

Tasks for next week :

  • Check duplicate patient base on first name, last name, middle name, birthdate, genre. If there is a patient existing, display all the information of that patient for user.
  • If a child < 5 years old. Then all of the identifier information should take from mother / father / guardian , So we have to put that person’s name to identifier information.
  • Bring all identifiers to patient registration screen.
  • System generated Random Unique Id. Organisation Unit name should not be in the Id.
  • Patient Identifier management.
    If there is anything that you think we can make it generic and merge to trunk, please tell.

Regards,

···

On Fri, Jan 29, 2010 at 2:06 PM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I assigned mandatory attributes under the patient registration screen.

Please find enclosed the attached file to see patch file.

Best regards,

================================
Châu Thu Trân

HISP Viet Nam
Email: tran.hispvietnam@gmail.com
Cell phone: +84 97 324 1542

2010/1/29 Lars Helge Øverland larshelge@gmail.com

On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I modify the source.

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

Best regards,

Nice work Tran…


Viet Nguyen

Hi,

In Vietnam, code of patient likes this:

  • Set of characters dependent on the organisation unit

  • Set of digits, include date and number of patients in the day.

···

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

================================

On Sat, Jan 30, 2010 at 6:14 PM, Viet Nguyen phamquocviet@gmail.com wrote:

Hi,

Here are things that I’ve changed for patient - branch

  • Add Date of Enrollment Description , Date of Incident Description for Program. This is because those description is differ from each program, when user enroll to a program, we need to show them the descriptions.
  • Move blood group to Patient table.
  • Merge Patient Attribute Group from trunk.
  • Add Patient Attribute Option . This is for any attribute that can have predefined value.
  • Bring all attribute groups to patient registration screen.

Tasks for next week :

  • Check duplicate patient base on first name, last name, middle name, birthdate, genre. If there is a patient existing, display all the information of that patient for user.
  • If a child < 5 years old. Then all of the identifier information should take from mother / father / guardian , So we have to put that person’s name to identifier information.
  • Bring all identifiers to patient registration screen.
  • System generated Random Unique Id. Organisation Unit name should not be in the Id.
  • Patient Identifier management.
    If there is anything that you think we can make it generic and merge to trunk, please tell.

Regards,

On Fri, Jan 29, 2010 at 2:06 PM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I assigned mandatory attributes under the patient registration screen.

Please find enclosed the attached file to see patch file.

Best regards,

================================
Châu Thu Trân

HISP Viet Nam
Email: tran.hispvietnam@gmail.com
Cell phone: +84 97 324 1542

2010/1/29 Lars Helge Øverland larshelge@gmail.com

On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I modify the source.

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

Best regards,

Nice work Tran…


Viet Nguyen


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

Hi,

The reason of not put the organisation unit in the System generated Patient Id is :

An organisation unit can be changed the name. Or it can be splited into two smaller organisation unit ( This is happening in India ) . Or even it can be merge with another organisationUnit to make a bigger one …

So we are thinking of an algorithm to generate the id for the whole country, but not depend on the organisation unit. It should only depend on patient information and the time of creating…

···

On Mon, Feb 1, 2010 at 8:25 AM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi,

In Vietnam, code of patient likes this:

  • Set of characters dependent on the organisation unit
  • Set of digits, include date and number of patients in the day.

================================
Châu Thu Trân
HISP Viet Nam
Email: tran.hispvietnam@gmail.com

Cell phone: +84 97 324 1542

================================

On Sat, Jan 30, 2010 at 6:14 PM, Viet Nguyen phamquocviet@gmail.com wrote:

Hi,

Here are things that I’ve changed for patient - branch

  • Add Date of Enrollment Description , Date of Incident Description for Program. This is because those description is differ from each program, when user enroll to a program, we need to show them the descriptions.
  • Move blood group to Patient table.
  • Merge Patient Attribute Group from trunk.
  • Add Patient Attribute Option . This is for any attribute that can have predefined value.
  • Bring all attribute groups to patient registration screen.

Tasks for next week :

  • Check duplicate patient base on first name, last name, middle name, birthdate, genre. If there is a patient existing, display all the information of that patient for user.
  • If a child < 5 years old. Then all of the identifier information should take from mother / father / guardian , So we have to put that person’s name to identifier information.
  • Bring all identifiers to patient registration screen.
  • System generated Random Unique Id. Organisation Unit name should not be in the Id.
  • Patient Identifier management.
    If there is anything that you think we can make it generic and merge to trunk, please tell.

Regards,

On Fri, Jan 29, 2010 at 2:06 PM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I assigned mandatory attributes under the patient registration screen.

Please find enclosed the attached file to see patch file.

Best regards,

================================
Châu Thu Trân

HISP Viet Nam
Email: tran.hispvietnam@gmail.com
Cell phone: +84 97 324 1542

2010/1/29 Lars Helge Øverland larshelge@gmail.com

On Thu, Jan 28, 2010 at 8:45 AM, Chau Thu Tran tran.hispvietnam@gmail.com wrote:

Hi Abyot,

I modify the source.

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

Best regards,

Nice work Tran…


Viet Nguyen


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