Quoting Karsten Hilbert <[EMAIL PROTECTED]>: > On Wed, Nov 30, 2005 at 04:11:42PM +1100, Ian Haywood wrote:
> > I would get rid of it. > No. Here's why: > > Form fields content are values extracted from the live > database, possibly slightly modified, for a given purpose. > They are not supposed to ever be changed after the fact. Now > a PDF would do for non-changeable form field items. But then > they would not be re-usable for filling in a, say, follow-up > form or re-creating the form with a slight variation > (because of mis-spelling, whatnot). That's right. But IMHO the better solution in that case is to leverage the existing audit tables by linking to a specific audit version which never changes. Did you get my self-reply? > > > - put ... clin.referrals in separate files, which can > > be loaded via the australia config files for the time being. > Done. Thanks. > > ... 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. Sure we can put ALTER TABLE commands in the australia schema files to add our specific stuff, particularly the Authority etc, that's appropriate. 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? 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. 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. > select not exists ( > select 1 from reviewed_documents where fk_document=XXX > ); > > to return True and have that mean "no one has reviewed that > particular document". 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. > 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. > > What do you think ? Do we really want/need that ? That's fine. I am happy with any solution. Yes we do want this information (who is supposed to review) in the clinical database so it's properly backed up. Ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
