Re: [Gnumed-devel] clin_health_issue - some thoughts

[J Busser]

At 8:20 PM +0100 11/17/04, Karsten Hilbert wrote:
> 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.

Two weeks was too short. Suppose a time frame long enough that, at a 
visit for an unrelated item, the doctor decides the episode of care 
for the single hypoglycemia episode (again the ambiguity of "episode" 
as EMR design vs clinical episode, but maybe clinical "event" helps) .

Anyway, after an (EMR) episode has been made "inactive", I can 
understand later attaching encountlets to the inactive episode, 
though to do so might make the most sense when the "late" encountlets 
represent defervescence, closure issues, maybe clinical "aftershocks" 
or "hiccups". I suppose that episode could again be made "active" 
because it is proving to have more activity which the doctor 
presumably had not expected at the time of making it "inactive". But 
I think if there is new or especially increased clinical activity, a 
new episode should more likely be declared.

Within any health_issue, once a new episode has been created, I 
cannot see that we would want the older episode to remain is_active. 
So if we keep it at all, is_active should have to be automatically 
set to inactive when a new episode is created (within an issue). 
Within the issue, from this point forward, we should probably be 
attaching episodelets only to the new episode. This is what I meant 
by superceded i.e. for *data entry purposes and future followup*, the 
prior episode has become superceded by the new one.

I wrote:

> > Perhaps the impetus to change an episode from is_active to "not"
> > is when it becomes superceded by a new episode

you replied:

> "next", not "superceeding", I think "superceding" wrongly
> suggests "following each other immediately"

The new episode only needs to follow the old episode *sequentially*, 
it does not matter if the transition is continuous or discontinuous. 
If in fact the old episode had been is_active until the moment of a 
new episode, in *database* terms  the new episode *does* follow 
"immediately".

> IMO [superceded] 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.

Yet when we make any EMR episode "inactive" we do not input a 
date/time for *when* it became inactive, just *that* it became 
inactive, so we have here no way to assert any such "period" of 
inactivity. "Activity / inactivity" seems meaningless. Your last EMR 
episode "activity" is defined by the last encounterlet. Your next EMR 
episode "activity" is defined by the next encounterlet. It seems to 
not matter semantically whether the episode had been labeled 
is_active, or not. The only other thing that could possibly translate 
into activity are the attached requests, consultations and any other 
type of plan items.

> 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

> what we then need the status for[?] - I think for
> distinguishing likelihood of importance for display.

Yes, this is what I raised several weeks ago. I suggested 
display_this but you did not (at that time) want the backend to be 
used to govern or dictate an interaction with a GUI client; the 
backend was only to store "intrinsic" properties of the data.

So that is why I am saying (as I might concur Ian) to let items 
attached to encounterlets determine whether an episode is_active, and 
drop the field. Unless what you want in its place is display_this or 
keep_open or similar some such field. The use-case could be when for 
any reason a clinician is stumped, or has some uneasy feeling about 
an episode which has no attached items (no active plan), but the 
clinician is thinking "maybe it should, and I must rethink at the 
next encounter if anything related seems to be going on".

If it is chosen to do without is_active (a term which still bothers 
me), then among multiple episodes (within a health_issue), the 
episodes can always be offered in reverse chronologic order, the most 
recent at the top (and the older ones optionally filtered out), 
because it is to this top one  that any new encounterlets should 
likely (and perhaps exclusively) be attached. I think that to back 
and add to (attach to) a "previous" episode we are perhaps talking 
about an audit e.g. a clarification to something collected/stated at 
an earlier encounterlet. In order to achieve this, we probably need 
something like 'show all" in order to unfilter the older episodes 
within an encounterlet.

My idea would be that the narrowest (top level) display filter 
includes each clin_health_issue which has
i.  an episode with attached items that are "active /not signed off" and/or
ii. a status of clinically_relevant
- as new encounterlets are more apt to be attached to (i), maybe a 
two-level sort order would be helpful

I can see how a health_issue could be coded clinically_relevant (or 
not) but within the issue I am having a harder time identifying the 
basis for making some episodes clinically_relevant and others not. 
Does this quantum simply cascade or (non-postgres) "inherit" upward, 
from encounterlet, so that if any one encounterlet within an episode 
is clinically_relevant, then the episode *must* be 
clinically_relevant and so must be the health_issue and conversely, 
if none of the encounterlets in any episodes within a health_issue 
were clinically_relevant, then the health_issue really can't be 
clinically_relevant, can it? So is clinically_relevant required only 
in the encounterlet?

Likewise, if there is early but uneasy agreement that "activity" is 
defined by items attached to encounterlets, but we are not sure how 
to code the 'active state" of attached items, do we (temporarily) 
need to keep user-definable is_active but only as an interim measure, 
and only in the encounterlet?