Some more points on the design of community-based system.
One thing very important, the whole point is not to build a medical record system but to build a feeder system to DHIS2 for specific programs like Family planning, Immunization and ANC - for the context of house-to-house service delivery and also at a facility. With a possibility for other programs…
With DHIS2 acting as a baseline for subsequent analysis, presentation, plotting, charting and graphing pulling the data into DHIS2 is very crucial and for that we are going to rely on aggregation service - which is yet to be implemented.
The way forward for the aggregation service, we planned, is to base on the concept of Multidimensional DataElement and use options and their combinations as drop-down choices for dataentry. For example we can have weight of baby as a dataelement and make Under Weight (xxx g. - yyy g.), Normal Weight (aaa g. - bbb g.) and Over Weight ( ccc g. - ddd g.) as options and will be used in dropdown for dataentry. Latter we can count Number of Babies Under Weight, Normal Weight and Over Weight and pass it to DHIS2. We can also have a summary, for example the number of condoms distributed during the month.
This will require us to classify our dataelements based on their type of aggregation operator for example type SUM, type COUNT and type BOOL - which we already have in the existing dataelement of DHIS2. But a limitation with this approach no free text is allowed in the system - may be the team from India can comment. I am only suggesting this approach from the experience of the Indian Line Listing module. Actually would be great if we could get the translated dataentry screens as soon as possible so that we make sure we are in the right track.
Would be happy to get comments - especially on any complex mode of aggregation - like other than counting summary and yes/no classification.
The focus is on house-to-house service delivery for an individual and its subsequent followup with a final goal of generating aggregate figure for DHIS2. At the same time the system should be capable of letting healthworkers record information at the facility.
And five points are visible in here - individual, house, service, followup and aggregation - which I think our datamodel should base upon. Individual’s grouped together and forming a family, a family with/with-out a house and a number of houses in a village belonging to a subcenter/facility is a context we will be facing out in the community. A health-worker should therefore plan ahead where to go, which house and which individual to meet, and what kind of service to provide. This requires for a strict planning of activity with inputs from standard health services and procedures (for example FP, ANC, Birth, Immunization, …) and current where about of individuals (making issues of migration another critical factor). In the end, the ground realtity (health status) of a particular village should be reflected in the overall country’s HMIS - aggregation and DHIS2.
Finally as per the discussion we made yesterday, the agreed plan is to follow the initial approach where we have everything implemented without using OpenMRS. And by the mid of October, the plan is to come up with a demonstratbale version leting users be able to
register individuals
register housholds
generate activityplans for ANMs
record observations from house-to-house visits of ANMs
Using OpenMRS would have been the ideal choice, especially when thinking of scaling and broader and stronger collaboration with OpenMRS team. But right now we don’t have a resource person (the one who can actually do the coding) who can be at the center of OpenMRS-DHIS2.
Note: I have committed the old code on lanuchpad. It can be checked-out from lp: ~dhis2-devs/dhis2/dhis2-chis/
What is currently in the code is an almost complete datamodel for the objects shown in the class diagram. For each of the given objects XXXService and XXXStore interfaces are provided together with their hibernate and service implementations.
The focus is on house-to-house service delivery for an individual and its subsequent followup with a final goal of generating aggregate figure for DHIS2. At the same time the system should be capable of letting healthworkers record information at the facility.
And five points are visible in here - individual, house, service, followup and aggregation - which I think our datamodel should base upon. Individual’s grouped together and forming a family, a family with/with-out a house and a number of houses in a village belonging to a subcenter/facility is a context we will be facing out in the community. A health-worker should therefore plan ahead where to go, which house and which individual to meet, and what kind of service to provide. This requires for a strict planning of activity with inputs from standard health services and procedures (for example FP, ANC, Birth, Immunization, …) and current where about of individuals (making issues of migration another critical factor). In the end, the ground realtity (health status) of a particular village should be reflected in the overall country’s HMIS - aggregation and DHIS2.
Finally as per the discussion we made yesterday, the agreed plan is to follow the initial approach where we have everything implemented without using OpenMRS. And by the mid of October, the plan is to come up with a demonstratbale version leting users be able to
register individuals
register housholds
generate activityplans for ANMs
record observations from house-to-house visits of ANMs
Using OpenMRS would have been the ideal choice, especially when thinking of scaling and broader and stronger collaboration with OpenMRS team. But right now we don’t have a resource person (the one who can actually do the coding) who can be at the center of OpenMRS-DHIS2.
Note: I have committed the old code on lanuchpad. It can be checked-out from lp: ~dhis2-devs/dhis2/dhis2-chis/
What is currently in the code is an almost complete datamodel for the objects shown in the class diagram. For each of the given objects XXXService and XXXStore interfaces are provided together with their hibernate and service implementations.
Thank you
Abyot.
Some more points on the design of community-based system.
One thing very important, the whole point is not to build a medical record system but to build a feeder system to DHIS2 for specific programs like Family planning, Immunization and ANC - for the context of house-to-house service delivery and also at a facility. With a possibility for other programs…
Good. I gather from previous discussion on this list that you are not keen on doing this through the openmrs jar. I think you have looked at the detailed issues so are in the best position to make an informed judgement. I am neutral in this regard. I do think that it is important that we do try to find a common approach for dealing with person level data (ie. for modules including and beyond the community based module) and I am confident you will do that.
With DHIS2 acting as a baseline for subsequent analysis, presentation, plotting, charting and graphing pulling the data into DHIS2 is very crucial and for that we are going to rely on aggregation service - which is yet to be implemented.
The way forward for the aggregation service, we planned, is to base on the concept of Multidimensional DataElement and use options and their combinations as drop-down choices for dataentry. For example we can have weight of baby as a dataelement and make Under Weight (xxx g. - yyy g.), Normal Weight (aaa g. - bbb g.) and Over Weight ( ccc g. - ddd g.) as options and will be used in dropdown for dataentry. Latter we can count Number of Babies Under Weight, Normal Weight and Over Weight and pass it to DHIS2. We can also have a summary, for example the number of condoms distributed during the month.
Very good. Just a thought to keep in mind which has come up from working with sdmx. Just as we have to share dataelement definitions we will also have to share categories (Dimensions) and options. It will be worthwhile to think about how we name them sensibly. The names you refer to above make a lot of sense - with I guess a category called something like BabyWeight. But some of the names I have seen in other existing implementations are a bit weird … I suppose it hasn’t mattered much as the whole multidimensional thing has been only used internally (dhis2 to dhis2).
This will require us to classify our dataelements based on their type of aggregation operator for example type SUM, type COUNT and type BOOL - which we already have in the existing dataelement of DHIS2. But a limitation with this approach no free text is allowed in the system - may be the team from India can comment. I am only suggesting this approach from the experience of the Indian Line Listing module. Actually would be great if we could get the translated dataentry screens as soon as possible so that we make sure we are in the right track.
I would like to see whether there is a real use case justification for free text dataelements as well. Obviously we want to allow maximum flexibility, but it is hard to understand, for example, what aggregation could or should mean in that context. There is also no mapping we can make with these dataelements and SDMX and other protocols. If it is possible to deprecate them and move towards dropping I would be in favour, but there might of course be another rationale for keeping them.
On aggregation some of the openMRS guys were talking last week about medians. Not sure if there is a real use case but there might be. Of course median of booleans is not that useful
Hi Abyot,
After quite a lot of struggle i managed to get the data model form the database. I have expanded only other table which are related to CHIS other i havent. See if i missed any table. I have commented about the CHIS data model and its problem how it may fail given different use cases. I tried to also explain possible solution for these problem.
Senor, The data model its not that bad as london pipe line.
John
The focus is on house-to-house service delivery for an individual and its subsequent followup with a final goal of generating aggregate figure for DHIS2. At the same time the system should be capable of letting healthworkers record information at the facility.
And five points are visible in here - individual, house, service, followup and aggregation - which I think our datamodel should base upon. Individual’s grouped together and forming a family, a family with/with-out a house and a number of houses in a village belonging to a subcenter/facility is a context we will be facing out in the community. A health-worker should therefore plan ahead where to go, which house and which individual to meet, and what kind of service to provide. This requires for a strict planning of activity with inputs from standard health services and procedures (for example FP, ANC, Birth, Immunization, …) and current where about of individuals (making issues of migration another critical factor). In the end, the ground realtity (health status) of a particular village should be reflected in the overall country’s HMIS - aggregation and DHIS2.
Finally as per the discussion we made yesterday, the agreed plan is to follow the initial approach where we have everything implemented without using OpenMRS. And by the mid of October, the plan is to come up with a demonstratbale version leting users be able to
register individuals
register housholds
generate activityplans for ANMs
record observations from house-to-house visits of ANMs
Using OpenMRS would have been the ideal choice, especially when thinking of scaling and broader and stronger collaboration with OpenMRS team. But right now we don’t have a resource person (the one who can actually do the coding) who can be at the center of OpenMRS-DHIS2.
Note: I have committed the old code on lanuchpad. It can be checked-out from lp: ~dhis2-devs/dhis2/dhis2-chis/
What is currently in the code is an almost complete datamodel for the objects shown in the class diagram. For each of the given objects XXXService and XXXStore interfaces are provided together with their hibernate and service implementations.
Thank you
Abyot.
Some more points on the design of community-based system.
One thing very important, the whole point is not to build a medical record system but to build a feeder system to DHIS2 for specific programs like Family planning, Immunization and ANC - for the context of house-to-house service delivery and also at a facility. With a possibility for other programs…
Good. I gather from previous discussion on this list that you are not keen on doing this through the openmrs jar. I think you have looked at the detailed issues so are in the best position to make an informed judgement. I am neutral in this regard. I do think that it is important that we do try to find a common approach for dealing with person level data (ie. for modules including and beyond the community based module) and I am confident you will do that.
With DHIS2 acting as a baseline for subsequent analysis, presentation, plotting, charting and graphing pulling the data into DHIS2 is very crucial and for that we are going to rely on aggregation service - which is yet to be implemented.
The way forward for the aggregation service, we planned, is to base on the concept of Multidimensional DataElement and use options and their combinations as drop-down choices for dataentry. For example we can have weight of baby as a dataelement and make Under Weight (xxx g. - yyy g.), Normal Weight (aaa g. - bbb g.) and Over Weight ( ccc g. - ddd g.) as options and will be used in dropdown for dataentry. Latter we can count Number of Babies Under Weight, Normal Weight and Over Weight and pass it to DHIS2. We can also have a summary, for example the number of condoms distributed during the month.
Very good. Just a thought to keep in mind which has come up from working with sdmx. Just as we have to share dataelement definitions we will also have to share categories (Dimensions) and options. It will be worthwhile to think about how we name them sensibly. The names you refer to above make a lot of sense - with I guess a category called something like BabyWeight. But some of the names I have seen in other existing implementations are a bit weird … I suppose it hasn’t mattered much as the whole multidimensional thing has been only used internally (dhis2 to dhis2).
This will require us to classify our dataelements based on their type of aggregation operator for example type SUM, type COUNT and type BOOL - which we already have in the existing dataelement of DHIS2. But a limitation with this approach no free text is allowed in the system - may be the team from India can comment. I am only suggesting this approach from the experience of the Indian Line Listing module. Actually would be great if we could get the translated dataentry screens as soon as possible so that we make sure we are in the right track.
I would like to see whether there is a real use case justification for free text dataelements as well. Obviously we want to allow maximum flexibility, but it is hard to understand, for example, what aggregation could or should mean in that context. There is also no mapping we can make with these dataelements and SDMX and other protocols. If it is possible to deprecate them and move towards dropping I would be in favour, but there might of course be another rationale for keeping them.
On aggregation some of the openMRS guys were talking last week about medians. Not sure if there is a real use case but there might be. Of course median of booleans is not that useful
Best regards
Bob
Would be happy to get comments - especially on any complex mode of aggregation - like other than counting summary and yes/no classification.
Thanks for sharing your thoughts. Its a very rich set of comments grounded in use cases which I will have to read over several times to fully appreciate. Just a few quick thoughts off the cuff:
I think Abyot’s model as it stands allows for multiple identifiers which is good. There should be some way in which the issuing authority of the identifier is held. I am guessing this is what the intent of the sourceid field is. I suppose it is a real likliehood is that a patient presents with a crumpled piece of paper with a file number or something from a particular facility. In this case we must not only record the number but also the issuing “authority”. In fact one might also need to have (yet another) table of “identifier_type” as there might be a wide variety of identifier types recorded. I suppose people come with what they have and we should be flexible enough to record that.
On addresses, two suggestions. Firstly I think the patient_address should better be called just “address”. An address is just an address after all. That a patient might have one is a good thing, but other persons or entities might have one too (see also below). Otherwise I like the way it currently stands whereby you might have multiple addresses for a patient but one preferred. This probably reflects reality - I think I prefer it to your patient attribute proposal. On the other hand I can also see the value in having a more general attribute table where arbitrary tags and values might be captured for a patient (starts to look a bit like rdf/a metadata).
Regarding duplication, you are right that the address seems to be duplicated between household and patient_address. I would suggest stripping the address stuff from household and simply make a link from household to address. So in the same way a patient has an address, so too a household has an address. And pursuing the logic other things (like orgunit for example) might also eventually make use of the address table as well.
All I have time for for now. Keep up the good work. And nice to see the diagram - what tool did you use to produce that?
Hi Abyot,
After quite a lot of struggle i managed to get the data model form the database. I have expanded only other table which are related to CHIS other i havent. See if i missed any table. I have commented about the CHIS data model and its problem how it may fail given different use cases. I tried to also explain possible solution for these problem.
Senor, The data model its not that bad as london pipe line.
John
The focus is on house-to-house service delivery for an individual and its subsequent followup with a final goal of generating aggregate figure for DHIS2. At the same time the system should be capable of letting healthworkers record information at the facility.
And five points are visible in here - individual, house, service, followup and aggregation - which I think our datamodel should base upon. Individual’s grouped together and forming a family, a family with/with-out a house and a number of houses in a village belonging to a subcenter/facility is a context we will be facing out in the community. A health-worker should therefore plan ahead where to go, which house and which individual to meet, and what kind of service to provide. This requires for a strict planning of activity with inputs from standard health services and procedures (for example FP, ANC, Birth, Immunization, …) and current where about of individuals (making issues of migration another critical factor). In the end, the ground realtity (health status) of a particular village should be reflected in the overall country’s HMIS - aggregation and DHIS2.
Finally as per the discussion we made yesterday, the agreed plan is to follow the initial approach where we have everything implemented without using OpenMRS. And by the mid of October, the plan is to come up with a demonstratbale version leting users be able to
register individuals
register housholds
generate activityplans for ANMs
record observations from house-to-house visits of ANMs
Using OpenMRS would have been the ideal choice, especially when thinking of scaling and broader and stronger collaboration with OpenMRS team. But right now we don’t have a resource person (the one who can actually do the coding) who can be at the center of OpenMRS-DHIS2.
Note: I have committed the old code on lanuchpad. It can be checked-out from lp: ~dhis2-devs/dhis2/dhis2-chis/
What is currently in the code is an almost complete datamodel for the objects shown in the class diagram. For each of the given objects XXXService and XXXStore interfaces are provided together with their hibernate and service implementations.
Thank you
Abyot.
Some more points on the design of community-based system.
One thing very important, the whole point is not to build a medical record system but to build a feeder system to DHIS2 for specific programs like Family planning, Immunization and ANC - for the context of house-to-house service delivery and also at a facility. With a possibility for other programs…
Good. I gather from previous discussion on this list that you are not keen on doing this through the openmrs jar. I think you have looked at the detailed issues so are in the best position to make an informed judgement. I am neutral in this regard. I do think that it is important that we do try to find a common approach for dealing with person level data (ie. for modules including and beyond the community based module) and I am confident you will do that.
With DHIS2 acting as a baseline for subsequent analysis, presentation, plotting, charting and graphing pulling the data into DHIS2 is very crucial and for that we are going to rely on aggregation service - which is yet to be implemented.
The way forward for the aggregation service, we planned, is to base on the concept of Multidimensional DataElement and use options and their combinations as drop-down choices for dataentry. For example we can have weight of baby as a dataelement and make Under Weight (xxx g. - yyy g.), Normal Weight (aaa g. - bbb g.) and Over Weight ( ccc g. - ddd g.) as options and will be used in dropdown for dataentry. Latter we can count Number of Babies Under Weight, Normal Weight and Over Weight and pass it to DHIS2. We can also have a summary, for example the number of condoms distributed during the month.
Very good. Just a thought to keep in mind which has come up from working with sdmx. Just as we have to share dataelement definitions we will also have to share categories (Dimensions) and options. It will be worthwhile to think about how we name them sensibly. The names you refer to above make a lot of sense - with I guess a category called something like BabyWeight. But some of the names I have seen in other existing implementations are a bit weird … I suppose it hasn’t mattered much as the whole multidimensional thing has been only used internally (dhis2 to dhis2).
This will require us to classify our dataelements based on their type of aggregation operator for example type SUM, type COUNT and type BOOL - which we already have in the existing dataelement of DHIS2. But a limitation with this approach no free text is allowed in the system - may be the team from India can comment. I am only suggesting this approach from the experience of the Indian Line Listing module. Actually would be great if we could get the translated dataentry screens as soon as possible so that we make sure we are in the right track.
I would like to see whether there is a real use case justification for free text dataelements as well. Obviously we want to allow maximum flexibility, but it is hard to understand, for example, what aggregation could or should mean in that context. There is also no mapping we can make with these dataelements and SDMX and other protocols. If it is possible to deprecate them and move towards dropping I would be in favour, but there might of course be another rationale for keeping them.
On aggregation some of the openMRS guys were talking last week about medians. Not sure if there is a real use case but there might be. Of course median of booleans is not that useful
Best regards
Bob
Would be happy to get comments - especially on any complex mode of aggregation - like other than counting summary and yes/no classification.
Thanks for sharing your thoughts. Its a very rich set of comments grounded in use cases which I will have to read over several times to fully appreciate. Just a few quick thoughts off the cuff:
I think Abyot’s model as it stands allows for multiple identifiers which is good. There should be some way in which the issuing authority of the identifier is held. I am guessing this is what the intent of the sourceid field is. I suppose it is a real likliehood is that a patient presents with a crumpled piece of paper with a file number or something from a particular facility. In this case we must not only record the number but also the issuing “authority”. In fact one might also need to have (yet another) table of “identifier_type” as there might be a wide variety of identifier types recorded. I suppose people come with what they have and we should be flexible enough to record that.
On addresses, two suggestions. Firstly I think the patient_address should better be called just “address”. An address is just an address after all. That a patient might have one is a good thing, but other persons or entities might have one too (see also below). Otherwise I like the way it currently stands whereby you might have multiple addresses for a patient but one preferred. This probably reflects reality - I think I prefer it to your patient attribute proposal. On the other hand I can also see the value in having a more general attribute table where arbitrary tags and values might be captured for a patient (starts to look a bit like rdf/a metadata).
Regarding duplication, you are right that the address seems to be duplicated between household and patient_address. I would suggest stripping the address stuff from household and simply make a link from household to address. So in the same way a patient has an address, so too a household has an address. And pursuing the logic other things (like orgunit for example) might also eventually make use of the address table as well.
All I have time for for now. Keep up the good work. And nice to see the diagram - what tool did you use to produce that?
Just a question. The business logic I had, based on the experience I got from a couple of field visits, is different from what you sent us now. Because what I had in mind is something focusing on registers or services and of course tracking. In your case the focus is the individual or the beneficiary.
And as you pointed out, the attachment you sent us is a draft - so my question is do you think it will be OK to stick with this draft? are we not going to suggest a new working practice? or you think that is what HISP India wants to introduce?
Would be great if we could get the remaining forms on the earliest possible so that we can do readjustments at the early stage.
Thank you
Abyot.
···
On Wed, Sep 23, 2009 at 10:41 AM, arunima s mukherjee arunimam@gmail.com wrote:
hi all,
enclosed pls find the initial draft of ANC Tracking Form…delivery & PNC details/form which need to be integrated with tracking will send in subsequent mail
John- pls check if all details covered and business logic right
Thanks for sharing your thoughts. Its a very rich set of comments grounded in use cases which I will have to read over several times to fully appreciate. Just a few quick thoughts off the cuff:
I think Abyot’s model as it stands allows for multiple identifiers which is good. There should be some way in which the issuing authority of the identifier is held. I am guessing this is what the intent of the sourceid field is. I suppose it is a real likliehood is that a patient presents with a crumpled piece of paper with a file number or something from a particular facility. In this case we must not only record the number but also the issuing “authority”. In fact one might also need to have (yet another) table of “identifier_type” as there might be a wide variety of identifier types recorded. I suppose people come with what they have and we should be flexible enough to record that.
On addresses, two suggestions. Firstly I think the patient_address should better be called just “address”. An address is just an address after all. That a patient might have one is a good thing, but other persons or entities might have one too (see also below). Otherwise I like the way it currently stands whereby you might have multiple addresses for a patient but one preferred. This probably reflects reality - I think I prefer it to your patient attribute proposal. On the other hand I can also see the value in having a more general attribute table where arbitrary tags and values might be captured for a patient (starts to look a bit like rdf/a metadata).
Regarding duplication, you are right that the address seems to be duplicated between household and patient_address. I would suggest stripping the address stuff from household and simply make a link from household to address. So in the same way a patient has an address, so too a household has an address. And pursuing the logic other things (like orgunit for example) might also eventually make use of the address table as well.
All I have time for for now. Keep up the good work. And nice to see the diagram - what tool did you use to produce that?
Bob, thanks for the valueable input.
John, have a look at this model diagram, I think what you say is missing / wrong is actually in place:
I was looking at the form you sent us. It looks more of a patient journal - in a way good as it will keep everything compact for the program’s life cycle, in your case ANC. And my question is will there not be fields which will be repeated during the program’s life cycle - for example those in page 2 and 3 of your form?
For ANC VISIT/ENCOUNTER DETAILS should we not record date of examination for each visits? Because what you have is only one filed “Date of examination”? Or what if we section the ANC visits? like First ANC Visits with all the dataelements and date of examination in one section, and another section for visit 2 and another one for visit 3.
Similarly in “Janani Surakha Yojna” section, how many times a pregnant woman is going to get a benefit? Is she paid only once or multiple times? The same question applies for the section “Referral”. Is there a possibility to refer the woman say for example during her First ANC visit, and also on the second visit or third visit?.. or there is only one referral?
Finally can we get the other forms you want us to consider? I still haven’t got the translated forms which I gave to Amit last time. Or you think the one you sent us is a replacement for those forms? Having all the forms very soon is crucial so that we can think a common business logic, serving all the cases, at the earliest.
Thank you
Abyot.
···
On Wed, Sep 23, 2009 at 11:55 AM, Abyot Gizaw abyota@gmail.com wrote:
Thank you Arunima !
Just a question. The business logic I had, based on the experience I got from a couple of field visits, is different from what you sent us now. Because what I had in mind is something focusing on registers or services and of course tracking. In your case the focus is the individual or the beneficiary.
And as you pointed out, the attachment you sent us is a draft - so my question is do you think it will be OK to stick with this draft? are we not going to suggest a new working practice? or you think that is what HISP India wants to introduce?
Would be great if we could get the remaining forms on the earliest possible so that we can do readjustments at the early stage.
Thank you
Abyot.
On Wed, Sep 23, 2009 at 10:41 AM, arunima s mukherjee arunimam@gmail.com wrote:
hi all,
enclosed pls find the initial draft of ANC Tracking Form…delivery & PNC details/form which need to be integrated with tracking will send in subsequent mail
John- pls check if all details covered and business logic right
Thanks for sharing your thoughts. Its a very rich set of comments grounded in use cases which I will have to read over several times to fully appreciate. Just a few quick thoughts off the cuff:
I think Abyot’s model as it stands allows for multiple identifiers which is good. There should be some way in which the issuing authority of the identifier is held. I am guessing this is what the intent of the sourceid field is. I suppose it is a real likliehood is that a patient presents with a crumpled piece of paper with a file number or something from a particular facility. In this case we must not only record the number but also the issuing “authority”. In fact one might also need to have (yet another) table of “identifier_type” as there might be a wide variety of identifier types recorded. I suppose people come with what they have and we should be flexible enough to record that.
On addresses, two suggestions. Firstly I think the patient_address should better be called just “address”. An address is just an address after all. That a patient might have one is a good thing, but other persons or entities might have one too (see also below). Otherwise I like the way it currently stands whereby you might have multiple addresses for a patient but one preferred. This probably reflects reality - I think I prefer it to your patient attribute proposal. On the other hand I can also see the value in having a more general attribute table where arbitrary tags and values might be captured for a patient (starts to look a bit like rdf/a metadata).
Regarding duplication, you are right that the address seems to be duplicated between household and patient_address. I would suggest stripping the address stuff from household and simply make a link from household to address. So in the same way a patient has an address, so too a household has an address. And pursuing the logic other things (like orgunit for example) might also eventually make use of the address table as well.
All I have time for for now. Keep up the good work. And nice to see the diagram - what tool did you use to produce that?
Bob, thanks for the valueable input.
John, have a look at this model diagram, I think what you say is missing / wrong is actually in place:
and how are you going to relate these tracking forms with household visits? are you going to suggest the health-extension workers go house-to-house carrying these tracking forms? I know there are some services which can not be given at a house-hold. But from the tracking forms you are suggesting - I couldn’t see a relation to house-to-house service delivery. Or are you thinking of summarizing the tracking forms (say for example missed visits) and tell health-extension workers to go house-to-house and urge individuals to show up for next visits or immunization camp areas?
Thank you
Abyot.
···
On Thu, Sep 24, 2009 at 10:03 AM, Abyot Gizaw abyota@gmail.com wrote:
Hi Arunima,
I was looking at the form you sent us. It looks more of a patient journal - in a way good as it will keep everything compact for the program’s life cycle, in your case ANC. And my question is will there not be fields which will be repeated during the program’s life cycle - for example those in page 2 and 3 of your form?
For ANC VISIT/ENCOUNTER DETAILS should we not record date of examination for each visits? Because what you have is only one filed “Date of examination”? Or what if we section the ANC visits? like First ANC Visits with all the dataelements and date of examination in one section, and another section for visit 2 and another one for visit 3.
Similarly in “Janani Surakha Yojna” section, how many times a pregnant woman is going to get a benefit? Is she paid only once or multiple times? The same question applies for the section “Referral”. Is there a possibility to refer the woman say for example during her First ANC visit, and also on the second visit or third visit?.. or there is only one referral?
Finally can we get the other forms you want us to consider? I still haven’t got the translated forms which I gave to Amit last time. Or you think the one you sent us is a replacement for those forms? Having all the forms very soon is crucial so that we can think a common business logic, serving all the cases, at the earliest.
Thank you
Abyot.
On Wed, Sep 23, 2009 at 11:55 AM, Abyot Gizaw abyota@gmail.com wrote:
Thank you Arunima !
Just a question. The business logic I had, based on the experience I got from a couple of field visits, is different from what you sent us now. Because what I had in mind is something focusing on registers or services and of course tracking. In your case the focus is the individual or the beneficiary.
And as you pointed out, the attachment you sent us is a draft - so my question is do you think it will be OK to stick with this draft? are we not going to suggest a new working practice? or you think that is what HISP India wants to introduce?
Would be great if we could get the remaining forms on the earliest possible so that we can do readjustments at the early stage.
Thank you
Abyot.
On Wed, Sep 23, 2009 at 10:41 AM, arunima s mukherjee arunimam@gmail.com wrote:
hi all,
enclosed pls find the initial draft of ANC Tracking Form…delivery & PNC details/form which need to be integrated with tracking will send in subsequent mail
John- pls check if all details covered and business logic right
Thanks for sharing your thoughts. Its a very rich set of comments grounded in use cases which I will have to read over several times to fully appreciate. Just a few quick thoughts off the cuff:
I think Abyot’s model as it stands allows for multiple identifiers which is good. There should be some way in which the issuing authority of the identifier is held. I am guessing this is what the intent of the sourceid field is. I suppose it is a real likliehood is that a patient presents with a crumpled piece of paper with a file number or something from a particular facility. In this case we must not only record the number but also the issuing “authority”. In fact one might also need to have (yet another) table of “identifier_type” as there might be a wide variety of identifier types recorded. I suppose people come with what they have and we should be flexible enough to record that.
On addresses, two suggestions. Firstly I think the patient_address should better be called just “address”. An address is just an address after all. That a patient might have one is a good thing, but other persons or entities might have one too (see also below). Otherwise I like the way it currently stands whereby you might have multiple addresses for a patient but one preferred. This probably reflects reality - I think I prefer it to your patient attribute proposal. On the other hand I can also see the value in having a more general attribute table where arbitrary tags and values might be captured for a patient (starts to look a bit like rdf/a metadata).
Regarding duplication, you are right that the address seems to be duplicated between household and patient_address. I would suggest stripping the address stuff from household and simply make a link from household to address. So in the same way a patient has an address, so too a household has an address. And pursuing the logic other things (like orgunit for example) might also eventually make use of the address table as well.
All I have time for for now. Keep up the good work. And nice to see the diagram - what tool did you use to produce that?
Bob, thanks for the valueable input.
John, have a look at this model diagram, I think what you say is missing / wrong is actually in place:
