[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] schema changes requested
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] schema changes requested |
Date: |
Wed, 07 Dec 2005 09:39:30 +1100 |
User-agent: |
Debian Thunderbird 1.0.7 (X11/20051017) |
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
Re: [Gnumed-devel] schema changes requested, Karsten Hilbert, 2005/12/07