Re: [Gnumed-devel] Re: schema changes requested

[Karsten Hilbert]

On Wed, Nov 30, 2005 at 05:24:34PM +1100, Ian Haywood wrote:

> > - forms_data seems to double up with the fields of 'real' tables that hold 
> > this data
> > such as referral, lab_request, medication, etc., I would get rid of it.
> > Instead each of these tables links to form_instances
> > with the data in form_instances and the fields of the table the form can be
> > re-created and re-edited as required.
> Hmm, that creates a problem when the user prints something then changes the
> clinical table. The old values will be there in the audit tables, but we can't
> link them to the form.
Yes we can but you answered your own suggestion.

> This has the advantage that
>       - clin_root_item descendants don't need explicit links
>       - one clin_root_item can have several forms printed off it,
But we cannot just slightly edit an item on one form but not
on another.

> This means forms can't have user-defined fields: fields must be 'real' fields
> in a SQL descendant or derived from them by the business object.
This, plus the fact that we cannot edit the item without it
showing up in the base table, is the knockout criterion for
me.

> I wouldn't make form_instances a clin_root_item
I agree. You are right. One form may be related to more than
one episode. Hence clin_root_itemizing each would mean it is
bound to one episode by default.

> or even auditable as these things
> are redundant: this table isn't meant to be updated
Hm, yeah, well, except that I re-print forms on a daily
basis. But hey, you are right. Those are *new* forms off the
old one.

> and is always linked to a clin_root_item.
We'll need a *many-to-one* table from episode to form --
which is nullable by concept.

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