dhis2-devs team mailing list archive

[Abyot Gizaw <abyota@xxxxxxxxx>]

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