On Fri, Dec 02, 2005 at 08:08:47AM +0800, [EMAIL PROTECTED] 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
