[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 

The exception is a multi-item script, but in this case we already have 
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]