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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
