gnumed-devel
[Top][All Lists]
Advanced

[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

Attachment: pgpFv7gB1_Hfn.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]