dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

2010/3/4 Viet Nguyen <phamquocviet@xxxxxxxxx>

>
>
> Hi Abyot,
>
>
> Any change you are making is fine with me as long as it makes sense to
> broader use cases. The ID for example is better if we could keep it as it
> was before. I remember the ID was made of organization unit code or short
> name plus a 5 (or 6??) digit number. It was made like this on the assumption
> that each registering unit will be a facility to serve a population of
> hundred thousand and remember that our assumption is this system is going to
> be used by the lowest possible health administrative units (at least as far
> as registration is concerned). And whenever a migration occurs we have to
> update the person's ID. We should only keep the UUID unique, unchanged and
> one-to-one. So the patient ID should be somewhat floating --- it could also
> be possible for a person to have more than one identifier.
>
> Let others discuss about this , then I do the coding part.
>
>
> Calculating birth date from a given age -  yes you will have conflicts if
> all ages are calculated relative to the first of January (that is how it is
> currently). But then your new approach makes sense if everyone if telling
> age relative to the current date.
>
> So this is not problem right :-)
>
>
> And the relationship type - instead of assuming there will always be
> parent/guardian vs child relationship, why don't you provide users with the
> list of available relationships so that they can choose ?
>
> This is all about validation. We give the user options for  choosing. Those
> options should be correct on logical meaning ...
>  IE: for the birthdate field, the rule is user can not select a date in the
> future. So we can just don't display all the future dates in the calendar,
> or let user choose then show error.
>
> The same thing happen to this relationship type. User adding a
> representative for a child, and we show them the relationship like  Child,
> Husband, Mother, etc...  is not correct .. Of course user can choose what is
> right. But on the side of the quality of an application, I think we should
> filter this list.
> We are not giving this software to STQC for testing now, but in the future
> I think India team will have to do that.
>
> There are some more functions that we plan to do :
>
> ** Paging *
>
> The list  patients will get really big, like  thousands ... So paging
> functionality is a must I think.
>
> There are some options to do this :
>
>    1. Paging on client side
>    2. Paging on server side, but  ajax loading the page.
>    3. Paging on server side, reload page.
>
> I prefer option 3, because I  won't have to change too much  the current
> layout ...
>
> ** Functionality for add a child after completing Delivery Stage*
>
> In India, there is another requirement : for mother care  program, after
> completing the Delivery stage, user want to add the child to the system
> immediately . They want a pop up after click on complete button....
>
> I'm thinking of create a new page call addRelationShipPatient  , where user
> can add a new patient/person that has relationship with another patient.  In
> this situation is a mother and a child.
>
> User can go to this page by click on a button "Add new patient"  in current
> Patient Relationship Management page.
>
> The addRelationShipPatient  page will be almost the same with the patient
> registration screen. Just only some small changes :
>
>    - Add a RelationShip type combo box on top of the form
>    - Don't show a pop up for adding new patient when user check on  "Is
>    Under age" , because we  already have the id of the patient .
>
> By the way, this is just the beginning , there will be many more India
> requirements that does not fit the gobal requirements. I think we should
> have a solution for this...If we can not come to an end for any problem....
> working on both patient-branch and trunk at the same time is fine with me.
>
> More things will come soon...
>
>
Hi Viet,

thanks for doing a great job both with coding and information. These
suggestions sounds sensible to me. Regarding the local-global requirement
issue I have strong faith in solving this through system settings and
generic solutions... Keep bringing the requirements on the table and we can
see how to find a solution to them.

Lars




> --
> Viet Nguyen
>
>