gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] schema changes requested


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] schema changes requested
Date: Wed, 7 Dec 2005 09:51:47 +0100
User-agent: Mutt/1.5.9i

On Wed, Dec 07, 2005 at 09:39:30AM +1100, Ian Haywood 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 ;-)
Oh, never mind that. We just buy used, failed asteroid
probes off the Japanese. These work quite well :-)

> Fair enough, it's occurred to me demanding 'proper' tables could
> quickly get out of hand.
Nevertheless I do see your point in being able to query
across fully relational clinical tables.

> IMHO form_instances.fk_audit integer references clin.root_item (pk_audit)
> should do, a separate linktable forms2episode seems over the top:
Well, I just suggested that so we can attach more than one
episode to the form instance...

> you generally are not going to associate a form with more than one epsiode at 
> once.
OK, fine by me, if you say so.

> 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.
OK.

> In fact, it may be best to have simply fk_encounter.
We already do :-)

create table clin.form_instances (
        ...
) inherits (clin.clin_root_item);

Let's keep at least the *originating* episode in that
fk_episode and not worry too much about correctnes as
related to each item of the content. In most cases it'll be
correct anyways as you say.

BTW, it just occurred to me that we need to include
form_data into v_narrative4search, thanks for pointing that
out.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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