Re: [Gnumed-devel] schema changes requested

[Karsten Hilbert]

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