On Sun, Jan 01, 2006 at 02:12:10PM -0800, Jim Busser wrote: > > > attached is a first attempt at the aust nips schedule which passes the > >> integrity constraints of the gnumed vaccination regime > >> schema. hopefully this is acceptable for the au database config. > >I have added it to the standard bootstrapping process and it works.
> 1. Does the standard bootstrapping process "read" some machine > configuration, to decide the country to which the machine is > configured (and if it finds none, prompt the user) and, with this > information, the bootstrapper installs country-specific data sets? No. It simply installs everything it is configured to install. It does prompt the user for decision on whether some things which aren't core to the database are to be installed (mainly data and, potentially, country-dependant tables etc). The database is designed in a way that it is intended to be possible to have data (such as vaccination schedules) from any region in the database concurrently and not have them get in the way of each other. That's one of my prime database design concepts. > It > is just that -- for example -- even though I live and work in Canada, > it would be useful for the tables to be populated with (for example ) > state/province/territory values for other countries on account of > travellers who may become patients. Exactly. Same with forms: assume the traveller brought along a standard discharge letter template from Poland that is supported by GNUmed - why not enable the user to print onto it ? > So it is helpful to clarify if we have a structure and process that > *limits* what gets imported as opposed to one that imports while > *preserving* country/region specific information so it can be > recognized and treated separately later, Neither, currently. a) there is no limit - provided the constraints are met - IOW if two countries insist on having the exact same name for a vaccination schedule that isn't possible. One has to budge. My solution in that case would be to name them "... (country A)" and "... (country B)". b) the base tables *simply hold data* - they don't care too much about business/legislative external constraints ! That's a key concept. The business rules are then possibly supported/superimposed by additional tables. For example: There are all kinds of work-cover forms in the database. However, for Germany it's only legal to use a single one from the list. Now, there would be a "configuration" table which defines which exact template to use if running in Germany. What we currently lack is the tagging of source data. Eg it is hard to impossible to decide which form template originated from which locale-dependant source file without external knowledge. When the need arises we will add it where needed. > 2. Specifically regarding what Syan has put together on top of > anything that already existed for vaccinations, is there any summary > useful for the wiki? Not really. It's just AU data. > Are there any key posts that describe main > design drivers? No. > If not, I can wait until I have a chance to "try" > these parts and ask from a user point of view. Surely. At that point user needs will become apparent. 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
