[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] clin_health_issue - some thoughts
From: |
Ian Haywood |
Subject: |
[Gnumed-devel] clin_health_issue - some thoughts |
Date: |
Sun, 14 Nov 2004 07:37:18 -0500 |
User-agent: |
Mutt/1.3.28i |
have read Jim's Wiki entry on the clin_health_issue.
I confess it left me somewhat confused (this is not a criticism, I
was confused before), I agree with its major points, but I would like
to make a couple of amendments clarifications.
> 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.
> 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)
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?)
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.
I would be nice to have triggers to enforce this rule of course.
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.
Ian
pgpFv7gB1_Hfn.pgp
Description: PGP signature
- [Gnumed-devel] clin_health_issue - some thoughts,
Ian Haywood <=