Re: [Gnumed-devel] schema changes requested

[ihaywood]

Quoting Karsten Hilbert <address@hidden>:

> 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