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
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
