2010/3/4 Viet Nguyen <[email protected]> > > > 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
