Re: [Gnumed-devel] schema changes requested

[Karsten Hilbert]

On Fri, Dec 02, 2005 at 08:08:47AM +0800, address@hidden wrote:

> > > ... clin.medications and  ...
> > I think clin.clin_medication is quite OK as it is. Feel free
> I wrote it (unless it's been changed) and it's crap.
It has been changed. Which doesn't mean it's no longer crap ;-)

> Sure we can put ALTER TABLE commands in the australia schema
> files to add our specific stuff, particularly the Authority etc,
> that's appropriate.
If it's really necessary to change the base tables I would
add tables *linking* to the base tables (in clin.).

> What's not appropriate is to have a totally separate, conceptually
> different, set of prescribing tables, which in turn implies complately
> separate business and GUI code. In that case, why work on the same project?
I was suggesting the "au." schema be used for AU style
prescriptions much like test_area/ in CVS: as a staging
place for experimentation from which the good stuff I'm sure
you'll come up with will flow into "clin.".

> There's nothing fundamentally 'Australian' about prescribing: we should
> be able to have a common base table and base business classes, even if
> we need to customise locally.
I absolutely agree.

> In particular I would like to have the core concept from Richard's schema:
> basically he normalises with respect to doctor's prescribing-habits, when used
> properly in the GUI with phrasewheels, this becomes very powerful.
I fully agree this is a powerful concept and I'd like to see
it as a core concept in our prescription tables. I think we
are getting in good shape here conceptually by merging
several good ideas:

1) Horst suggested and projected the always-up-to-date
reference data source with a uniform API in the incarnation
of drugref.

2) Hilmar suggested an intermediate data store for basic
drug data (name etc) - filled from the reference source when
used - right in the clinical schema. This data store will
never lose drugs that go out of market (they are merely
disabled) -- unlike the reference source.

3) Richard suggested this intermediate data store be "keyed"
on "drug names as the doctor used them" and then linking to
that store from a) scripts (really ?) and b) curr_medication
of each patient (instead of storing them with each patient).

Taken together this seems like a plan to me.

> >  select not exists (
> >     select 1 from reviewed_documents where fk_document=XXX
> >  );
> > 
> IMHO this is will unusably slow with a big database,
> but you are right: only time will tell and we should leave optimisation
> until later.
*If* time proves you right we will use a materialized view.

> > IOW, we'd need to add the field to doc_obj and test_result
> > etc etc. which is fine with me.
> > Also I would surely call it fk_*intended*_reviewer.
> That's fine. I am happy with any solution.
Done.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346