[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] clin_health_issue - some thoughts

From: J Busser
Subject: Re: [Gnumed-devel] clin_health_issue - some thoughts
Date: Fri, 19 Nov 2004 01:00:17 -0800

At 6:04 PM +1100 11/19/04, Ian Haywood wrote:
 > because it is to this top one  that any new encounterlets should
 likely (and perhaps exclusively) be attached. I think that to back
I have always wondered why episodes can't be inferred directly via timeouts...

...I'm not sure how useful "is_active" really is, even if you declare an issue "closed", you never know when the patient is going to come back with a recurrence, treatment failure, etc., it's only really closed when a reasonable amount of time has elapsed.

generally the time within which a role reassessment might reasonably be contemplated (even if you had not anticipated the need for this particular patient)

IMHO there is one concept, a continuous variable: the "importance" of a health issue, determining how they are displayed

determining how the "importance" order is displayed (because chronology is for example a competing useful display order depending on what is being explored / considered - but agree. I had suggested clinically_important as a minor naming change from clinically_relevant. I am not sure how we would handle (assess/input) a continuous variable.

(most important at the top) (episodes can't be important or not, as they are strictly time-sequential and will always be displayed in reverse-chronological order.) This, again, should be inferred, a health issue is important if there have been recent episodes, moreso if there are any outstanding results, recalls, etc, so as time passes, the health_issue floats down the list into irrelevance (but should never vanish completely)

I like this approach

 > In trying to better understand the relationships of the problems to
 each other, it can be helpful (as an option) to be able to have a
 user-controllable grouping or sort order. I will try and make the
 case for it in some use cases.
Please don't add a fourth layer to the issue-episode-item hierarchy.
Remember diagnoses linked to clin_diag can be grouped under health issues (some of the item on Richard's list would be such entries in clin_diag under a health issue, rather than issues in their own right,of course we can debate exactly which, but each user can decide for him/herself when entering the data)

I was thinking that it might be handled softly within the _issue table e.g. by prepending sort characters within a field, combined with the naming assigned to the issues. For example I find it helpful to sort "adjacent" a patient's angina, status-post MI and post-CABG, heart failure and renal failure, it certainly helps when reviewing the rationale for a current drug regimen. AFAICT the only downside to people who think this "fiddly" (they wouldn't have to *adopt* it as a local practice) would be the presence of a sort field input box, which they might have to ignore unless it could be configured out.

reply via email to

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