dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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@xxxxxxxxx>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
>
> Lars - could not open the link you sent
> regards
> arunima
> 2009/9/22 Lars Helge Øverland <larshelge@xxxxxxxxx>
>
>
>>
>> 2009/9/22 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?
>>>
>>>
>>
>> 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:
>>
>>
>> http://docs.google.com/gview?a=v&pid=gmail&attid=0.1&thid=123cd0e47a40a6b5&mt=application%2Fpdf&url=http%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3D2%26ik%3Db4dafba814%26view%3Datt%26th%3D123cd0e47a40a6b5%26attid%3D0.1%26disp%3Dattd%26realattid%3Df_fzqvtrhg0%26zw&sig=AHBy-hb-G-lRemar2JW3IbAOpio-xzw9PA
>>
>>
>> Lars
>>
>>
>
>