gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] clin_health_issue - some thoughts


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] clin_health_issue - some thoughts
Date: Wed, 17 Nov 2004 20:20:33 +0100
User-agent: Mutt/1.3.22.1i

> I think we want to understand how adequately would the health_issue / 
> episode / diagnosis schema meet our clinical needs.
I don't consider issue/episode to be of the same
organisational quality as diagnosis.

Actually, semantically it should be grouped encounter/episode
vs. issue/diagnosis/AOE/Assessment.

Encounter/episode concern themselves (IMO) with temporal
issues. Encounters simply occur and have fairly well
defined temporal boundaries. Episodes less so but they still
"just occur". Their starting/ending is pretty much at the
discreetion of human decision with some reasonable heuristics
applied for default behaviour. Encounters can be started/ended
by a machine with much greater confidence.

> thread of care encounterlets (my term, if people will suffer it, to 
Encountlets ? (I realize that's probably linguistically
questionable but is shorter to type.)

> Whether a user bothers to segment this longtitudinal thread into 
> discrete episodes is entirely optional and two clinicians might 
> choose different cutpoints.
Agree.

> It is interesting to consider that after 
> a clinician flagged an episode to have become "inactive", a patient 
> could return to ask questions, or obtain clarification, that does not 
> really warrant a "new" episode, so can we permit a new encounterlet 
> to be attached back to the most recent, pertinent episode even though 
> it was already changed to inactive?
Sure. The "inactive" was just what the clinician *though* not
what was really going on - eg. it *really* wasn't inactive
yet. Depending on what the patient wants we can leave it
inactive (eg she seeks clarificiation "just one more time") or
re-activate it.

> Perhaps the impetus to change an episode from is_active to "not" is 
> when it becomes superceded by a new episode
IMO this would mean the previous episode has ended sometime
earlier already followed by an "episode" (eg. period) of
*inactivity*. Which is pretty much the best of definition of
episode I can come up with: Periods of activity between
periods of inactivity. Note that there is no reference to the
quantity of activity, just either or. Of course, clinically
all this is under the discreetion of the people concerned
because it would mean that chronic diseases never have
inactive periods. On average one would label "well controlled
IDDM with normal HbA1c" as inactive - while in fact the
patient does suffer IDDM, of course.

>, as warranted by some new 
> development (as suggested for example by Karsten in a previous email 
> e.g. at a point of "loss of BP control")
This would be a qualitative change in activity, eg. "now
symptomatic high BP" while previously "non-symptomatic". In
your nondiabetic student with hypoglycemic spells example I
didn't see two episodes occurring - even though part of it
seemed walk-in GP encounter of fatigue while the other appeared
to have been ambulanced ER care - certainly a difference in
level of care. Both, however, apparently occurring within a
closely related timeframe and (to me) belonging to the same
episode.

> In this case, the function 
> of is_active becomes instead is_open (or its opposite, is_closed) to 
> denote that beyond a certain point, no further encounterlets should 
> be attached, because they should instead be linked to the 
> superceding, "open" (not closed) episode.
"next", not "superceeding", I think "superceding" wrongly
suggests "following each other immediately"

Is_open does sound a bit more intuitive, perhaps. I would
never technically prevent being able to attach more
encountlets to any episode regardless of status. Which begs
the question what we then need the status for - I think for
distinguishing likelihood of importance for display.

> In database terms, the is_active column just served to communicate 
> that that the (computer) episode status remained "active", but this 
> terminology competes with our clinical mode ("active" health issues, 
> disease).
A good point. We *might* want to change it. However, Ian
already said at some point that *actually* the status of an
episode is defined by it's members, eg. if any attached item
is active then the episode is open. We need more thought on
this but it does have merit.

> Patients who feel better, and whose problems may in fact 
> have become inactive, may decline to come back until a need arises. 
> When they next come back, perhaps for some other issue, you may 
> discern that earlier *clinical* episode may not have been "active" at 
> all. More correctly, it is just that the (computer documentation) 
> episode has remained "open".
Absolutely, at which point you can opt to close them.

> Is_open might serve a clearer purpose, as above. Now some may be 
> thinking "well, we still need is_active as the basis to filter (in) 
> episodes of interest" - but do we? That which is not 
> "clinically_relevant" will not be very important, but may need to 
> stay in view because there are still actions pending e.g. a need to 
> see the patient again in followup, a test request whose result is not 
> yet returned, a quick phone discussion you need to have with a 
> colleague / consultant. *** But *** I would say  "why not let the 
> existence, or lack, of such things be the determinant of whether an 
> episode is 'active'".? After all, why would you want to keep in view 
> an episode that was "active" yet for which there are no incomplete or 
> unreviewed tasks, results, or plans/arrangements for the patient to 
> come back?
This is certainly the right way in a clinical sense but I
think it's a bit messy to do technically. A bit like your
earlier discussion on how it's easier to keep todo items
aggregated with pointers to details.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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