Re: [Gnumed-devel] clin_health_issue - some thoughts

[Karsten Hilbert]

>  > The "problem list" is a view over issues and episodes selectable by
>  > is_active and (via linked clin_diag) clinically_relevant.
>  Directly linking health_issues with clin_diag entries already weakens
>  the dangerous;y thin conceptual line between what is a health issue 
>  and what is a diagnosis,
>  instead we should stick with an uncoded, overarching "issue" linking
>  one or more (possibly coded) clin_diag entries.
>  Remember clin_health_issue has its own is_active and
>  clinically_relevant flags, it doesn't need this link.
And it doesn't have it, currently. I once wondered whether
epidodes and issues shouldn't have any narrative fields at all
by themselves but rather should get associated with a particular
clin_narrative row (which might progress from RFE to subj to
obj to assessment to diagnosis over time) which is probably
where the above statement arose from.

>  > a health issue must not necessarily have an episode - this allows us
>  > to enter "proven" diagnoses from the past history as "problems" or
>  > IOW as health issues 
>  I disagree, health_issues can't be coded, and each item of the past
>  history doesn't constitute a health_issue, again the distinction with
>  clin_diag is blurred.
>  Instead, inactive past history should be entered as clin_diag,
>  marked is_active='f', probably linked to the default episode
>  (or maybe a special "past history" episode)
The reasoning was that past history items were likely mostly
going to be past diagnoses made by other doctors. (Initially I
was confused about the past *history* term but people educated
me that it pertains to past *diagnoses*.) In that sense those
are likely health issues, either active or not, either
clinically relevant or not. Also, they may not be that
rock-solid, eg "had gynecological procedure done in 79" and we
don't know whether that was hysterectomy, uteropexis, whatnot.
Nevertheless it's a significant past history item - but not a
diagnosis, let alone a codeable one. OTOH, you are right, it's
not helpful that we cannot code a health issue should we want
to. It could be argued that in such cases one might still
enter a health issue/episode/clin_diag and code that where the
issue/episode draw their name from the clin_diag. Which,
however, is fairly convoluted. Which, in turn, led me to the
idea that issues/episodes shouldn't have names in the first
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).

>  clinically_relevant and is_active occur at all three levels
>  (clin_health_issue, episode, clin_diag), the sematic relationships need
>  to be defined. (what does an active diagnosis in a inactive episode
>  mean?)
I know :-(  See above for not naming issues/episode directly.

>  IMHO, an episode is automaticly active (or clinically_relevant) if it has 
> one or more active clin_diag, and similarily a heath_issue is active if it 
> has 
>  one or more active episode, so the flags at higher levels are merely to
>  cache their state instead of having to recalculate all the time.
Can you positively ascertain that ? What about issues without
episodes or episodes without a clin_diag attached ?

>  I would be nice to have triggers to enforce this rule of course.
If we are clear on the logic that part is doable.

>  We also need to give some effort to thinking how to present all this
>  hierarchy for manipulation (after entering diagnosies via soAp). 
>  Unfortunately, I see little option other
>  than a tree widget with popup menus, for deleting/changing/adding
> the various elements, even if we opt for "flat" presentation of the 
> history narrative.
Well, for manipulation of issues/episodes/encounters and moving
clin_narrative around between them a tree widget might do just
fine as it is bound to happen "fairly" rarely I would think.
At least not under constrained time conditions.

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