Karsten Hilbert wrote:
> > 2) the form associated with a probe on it's way to the lab > (and back, perhaps ?) Sending probes to the lab? That must cost you a lot ;-) > This will include just the things the politicians' whim of > the day will require us to put onto it. It is *part* of the > above. Fair enough, it's occurred to me demanding 'proper' tables could quickly get out of hand. Disc is cheap, after all. > I don't have too much of a problem linking form instances to > certain other tables for cross-checking. IMHO form_instances.fk_audit integer references clin.root_item (pk_audit) should do, a separate linktable forms2episode seems over the top: you generally are not going to associate a form with more than one epsiode at once. The exception is a multi-item script, but in this case we already have curr_medication, so which epsiode the script form is associated with is immaterial. In fact, it may be best to have simply fk_encounter. >>When we re-edit the data (which your not going to do very often for a lab >>request I admit) >>which do we draw from: lab_request or form_data? > > A very good question. It's going to have to be bit at the > discretion of the user and the GUI will have to allow for > that. Just reprinting the form can easily be done - even > with minor changes via form_data. The form_data stuff is > more intended for keeping around what the form was like, > eventually, it is not intended for relational re-use in the > database. Ok, sounds good. Ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
