[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] clin_health_issue - some thoughts
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] clin_health_issue - some thoughts |
Date: |
Sun, 14 Nov 2004 10:48:24 -0500 |
User-agent: |
Mutt/1.3.28i |
On Sun, Nov 14, 2004 at 01:54:26PM +0100, Karsten Hilbert wrote:
> diagnosis, let alone a codeable one. OTOH, you are right, it's
> not helpful that we cannot code a health issue should we want
Allowing such coding blurs the line even further, we end up with 3
tables with the same fields but different nsmes.
> place but rather be associated with particular clin_narrative
> items by virtue of which they would automatically be
> categorizable (level of evidence, eg. SOAP), codeable
> (since any clin_narrative is codeable), and or taggable
> (relevant/active).
Is it possible to overhaul the is_aoe/is_rfe/is_active/is_relevant
flag collection so we can make health_issue and episode pure views
on clin_narr?
That is, replace with "defines_episode", "defines_health_issue",
and "is_active"? This solves the comlexity and avoids data duplication.
It also makes it easy to "demote" or "promote" things from health_issue
status.
Problem is, AFAICT you can't have a reference constraint on a view,
so we need to hand-write a few triggers to enforce the
issue-episode-narrative hierarchy.
Ian
pgp7VsLMzXfjS.pgp
Description: PGP signature