Re: [Gnumed-devel] clin_health_issue - some thoughts

[Karsten Hilbert]

> 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 think that is what would usually happen. Or an unexpected
eruption of activity.

> 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".
I agree.

> But 
> I think if there is new or especially increased clinical activity, a 
> new episode should more likely be declared.
This is at the discreetion of the clinician.

> 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.
Agree. One could think of episodes as being "symptoms" of
"issues". Every once in a while a symptom becomes bothering to
the patient. This would then constitute an episode.

> 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). 
I am not so sure. Consider this use case:

 1996 traffic accident with polytrauma

In my charts this would become a health issue

 "post-polytrauma (traffic acc '96)"

Suppose that patient suffers several long-term problems from
that.

1) recurrent back pain
2) an episode of osteomyelitis at the site of metal plating

I can perfectly imagine each of such episodes being active at
the same time, eg.

 "lower back pain 8/04"
 "post-traumatic osteomyelitis left calf 8/04"

Both would be linked to the traffic accident health issue, of
course. Both episodes are is_open.

Does that make sense ?

> Within the issue, from this point forward, we should probably be 
> attaching episodelets only to the new episode.
See above.

> >"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. 
That is true. However, I believe the decision whether a new
episode supercedes an old episode (thereby closing it
forever) or whether it's a new episode on the same issue
is at the discreetion of the treating clinician.

> 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.
The middleware also already supports
get_first/last_encounter().

> 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;
neither do I now

> 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.
In that case one would have to scan a fair bit of the database
to determine whether to consider an episode open or closed.
And even then one might want to be able to *declare* a
seemingly closed episode to be open or vice versa.

> Unless what you want in its place is display_this or 
> keep_open
  ^^^^^^^^^
  Which isn't much different from is_open ?

> 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
Which would mean that either some episodes would *always*
remain open because we declared a particular lab result as
clinically_relevant, for example, or we would have to set such
clinically_relevant fields to false when closing an episode -
now, I don't think so ...

> 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.
I agree. The relevant field should probably be removed. Either
health issues or clin_root_item descendants can be
clinically_relevant as they are facts about the state of
health while an episode denotes an open/close *period* of time
of dealing with a problem.

> 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?
I don't think so. See the lab value example.

> 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?
The encounterlet per se does not exist as a separate object in
the schema. Either we have is_open on the clin_episode (which
we do) or we have clinically_relevant on all clin_root_items
(which do not yet have). Is-open serves well for now, I guess.

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