Hi John, 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? Regards Bob 2009/9/22 John lewis <[email protected]> > 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 <[email protected]>wrote: > >> Hi Abyot >> >> 2009/9/21 Abyot Gizaw <[email protected]> >> >>> >>> >>> 2009/9/18 Abyot Gizaw <[email protected]> >>> >>>> 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 : [email protected] >>> Unsubscribe : >>> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
