[Top][All Lists]

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

Re: [Gnumed-devel] clin_health_issue - some thoughts

From: J Busser
Subject: Re: [Gnumed-devel] clin_health_issue - some thoughts
Date: Thu, 18 Nov 2004 08:41:22 -0800

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

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?

reply via email to

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