Re: [Gnumed-devel] clin_health_issue - some thoughts

[Ian Haywood]

On Thu, 18 Nov 2004 08:41:22 -0800
J Busser <address@hidden> wrote:

> because it is to this top one  that any new encounterlets should 
> likely (and perhaps exclusively) be attached. I think that to back 
                      ^^^^^^^^^^^
IMHO this is a must, else my understanding of episode is totally wrong.
I have always wondered why episodes can't be inferred directly
via timeouts (as we currently do with encounters), but on a larger scale. So if 
we try to add something to a health issue after a week, [almost] obviously  
that is part of the latest episode, after a year, obviously a new episode. 
Obviously we have configurable 'hard' and 'soft' timeouts (i.e "1 week", and "6 
months" as defaults) with a Yes/No popup for the in-between case were the user 
must decide whether this is a new episode or not.

With is_active, is_clinically_relevant, etc., truth be told, I've never been 
happy with these flags, especially at different levels in the hierarchy, with 
no clear sematic meaning at the various levels (I'm not even convinced 'active' 
and 'clinically_relevant' are separate concepts.) The GUI is going to be a mess 
with tickboxes all over the place, and ticking them a right royal pain. 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.

IMHO there is one concept, a continuous variable: the "importance" of a health 
issue, determining how they are displayed (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)

This means clin_diag needs an "actual_time" field, so when the 
patient reports their open chole in 1979, that goes straight to be bottom of 
the list, even though encounter.date is today. (the parser can look for 4-digit 
numbers between, say, 1900 and the current year)
This should actually be the "fuzzy date" type that was mooted ages ago.

> 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)

Ian


-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgp5SCFbtzJfM.pgp
Description: PGP signature