> >My preference was to keep org and v_basic_person consistent on the > >backend, but I can see this is a losing battle. I've put getId () > >back. I just missed that. doing org.id -> org.pk_identity would be OK with me.
> Richard and Ian seem each now to be working on demographics & I > surmise also GUI widget development (though I am not sure if Ian > works in horst-space or richard-space). In new-richard-space. Unaptly called HorstSpace :-( for historical reasons. > What is the best way to get demographics working in the shortest > time, using the people currently involved? How do we clear the way? I would suggest just letting them (Ian and Richard) go on. > (a) what more of the demographic functionality for 0.1 is needed to > be defined, and let us assure the RoadMap contains the needed detail "Better" defined would perhaps help. > (b) after (a) shall we examine the relevant tables in the schema to > identify anything extra that should be added or modified (including > any changes of name), doing so, and then *delay* changes EXCEPT as > required by demographics, until after 0.1 I would suggest delaying unnecessary changes in the schema from right now. > (c) can we figure out to get the db schema as generated by PG autodoc > to reflect it? is the cron job running yes > and is it tripping over anything? no > (d) I am new to objects (the classes & API etc) but imagine if they > get renamed or restructured then that, too, will break things and yes > might be nice to avoid breaking. Can we identify what issues / needs > demographics would have of the objects and again try to freeze or > minimally disturb them except as demographics requires during its 0.1 > construction? At the very least I would suggest to rename cOrg to cParty which makes a whole lot more sense (to me). > Can we assemble whatever is the to-do list and maybe move what is > currently on the RoadMap page to a new page like > PatientCreationAndModification linked from the roadmap, yes > - should Search be included here? no, extra page, I would assume Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
