gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] emrjounalplugin.py comments further html work


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] emrjounalplugin.py comments further html work
Date: Mon, 19 Sep 2005 13:01:05 +0200
User-agent: Mutt/1.5.9i

On Sun, Sep 18, 2005 at 11:39:51PM -0700, Jim Busser wrote:

> And how are your many-to-one relationships between multiple problems, 
> and a particular progress note, stored in the mini-gnumed backend?  I 
> don't believe GNUmed proper, as its schema is currently defined, 
> would support that (?)
You are correct. It does not support that as it stands.

> Karsten, are these approaches (current GNUmed vs Horst's in which a 
> single note record can be linked to multiple problems) incompatible 
> in the same schema?
No. We could add an auxiliary link table

 table lnk_aux_narr2epi
        pk serial primary key
        fk_episode integer references clin_episode(pk)
        fk_narrative integer references clin_narrative(pk)

which would allow linking arbitrary narrative rows to
additional problems. Now, there would need to be additional
frontend support for that.

What is the level of detail you would want to allow linking
a "single note record" to multiple "problems" ?

If at the clin_narrative row level the above approach would
be possible (lnk_aux_narr2epi). If at the level of an
"entire progress note" (whatever that means) we would need
to take another approach:

 table clin_multi_problem_notes
        pk serial primary_key
        narrative text
        check constraint soap_cat=='u'          (as Ian suggested)
 inherits (clin_root_item)

 table lnk_multi_note2epi
        pk_multi_note integer
        pk_problem integer
        unique(pk_multi_note, pk_problem)

So, pick your poison.

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]