|
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 shouldlikely (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 toeach 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.
[Prev in Thread] | Current Thread | [Next in Thread] |