form_instance vs. lab_request Let me try to explain. Why two tables holding (apparently) the same data ? IMO we are dealing with two different things here even if closely related in quite a few cases overlapping quite a lot.
1) the business process of "getting a blood sample off to the lab with all the proper work on the by" This may potentially include things such as - told nurse to draw sample - told secretary to call lab pickup - noticed improperly cooled probe - added notes about improperly cooled probe - printed associating form (hey ;-) - handed over to lab pickup - noticed printed form went missing - reprinted form correcting a speling misteke - faxed form to lab - phoned after results etc, etc This part of the world is represented by a row in lab_request. 2) the form associated with a probe on it's way to the lab (and back, perhaps ?) 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. The distinction is perhaps clearer with script vs. curr_medication. > so we put the data in clin.lab_request via the business layer, no problems > there (I assume). I agree. > Presumably, when we print you what the same data saved again in forms_data. > Why? Because lab_request may and will eventually reach farther than the simple form itself. And certainly we want to be able to have unified lab_request while we will certainly also want to be able to use each locale's forms for it. > (when we can put lab_request.pk_audit in form_instances to ensure the data > matches the form) I don't have too much of a problem linking form instances to certain other tables for cross-checking. > 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. That would be served by a PDF as well, however, it does make practical sense to be able to access the fields one by one. Trust me. Been there done that. Here (as in "in some of the better German systems") it works thusly: Hit F1 to start a new script then hit F7 to reload old values (form_data) into it. Or hit Ctrl-L (load) to allow selection of data from the electronic chart (lab_request). 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
