Re: [Gnumed-devel] aust national immunization program schedule

[Karsten Hilbert]

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