| Thread Previous • Date Previous • Date Next • Thread Next |
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 On Mon, Sep 21, 2009 at 7:59 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote: > Hi Abyot > > 2009/9/21 Abyot Gizaw <abyota@xxxxxxxxx> > >> >> >> 2009/9/18 Abyot Gizaw <abyota@xxxxxxxxx> >> >>> Hi All, >>> >>> Please find the attached. >>> >>> 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 >>> >>> 1. register individuals >>> 2. register housholds >>> 3. generate activityplans for ANMs >>> 4. 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. >> >> >> Thank you >> Abyot. >> >> >> >> >> >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> Post to : dhis2-devs@xxxxxxxxxxxxxxxxxxx >> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> More help : https://help.launchpad.net/ListHelp >> >> >
Attachment:
CHIS_Abyot2.pdf
Description: Adobe PDF document
Attachment:
CHISComment.doc
Description: MS-Word document
| Thread Previous • Date Previous • Date Next • Thread Next |
