dhis2-devs team mailing list archive

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

-- 
Viet Nguyen