dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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 <johnlewis.hisp@xxxxxxxxx>

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