Re: [Gnumed-devel] clin_health_issue - some thoughts

[J Busser]

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.