Re: [Gnumed-devel] clin_health_issue - some thoughts

[Karsten Hilbert]

> > 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.
Well, my wishful thinking rather went into the direction of
abolishing the "description" field in clin_health_issue and
clin_episode. To make up for that a mechanism needs to be
invented to mark a given clin_narrative row to be the defining
name for the episode/issue - which brings me to think that
your suggestion of two flag fields (defines_episode,
defines_issue) sounds like it ?

> > 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?
Yes and no. I don't think we can make them pure views because
they might serve defining purposes beyond the naming.

Is_aoe/is_rfe is encounter related and not immediately a
concern for this step.

I'll try to propose a structure this week that implements the
defines_* fields in clin_narrative thereby consolidating the
is_active/is_clinically_relevant business if no one objects.

It just *might* turn out that we *can* make them pure views
after all. We'll have to see and proceed in careful steps.
None of this is really relevant to the frontend since any
changes are going to be absorbed by the middleware.

Further discussion welcome.

> That is, replace with "defines_episode", "defines_health_issue",
> and "is_active"? This solves the comlexity and avoids data duplication.
Note, however, that this doesn't solve the is_aoe/is_rfe thing
which I would suggest to keep for a second step.

> It also makes it easy to "demote" or "promote" things from health_issue
> status.
Absolutely, that is the intent.

> 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.
Not sure we'll need that. I harbor the gut feeling that it'll
be solvable by appropriate conditional constraints on the base
table(s).

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