[Top][All Lists]
[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, 24 Nov 2004 16:05:46 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> 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
- Re: [Gnumed-devel] clin_health_issue - some thoughts, (continued)
- [Gnumed-devel] Aggregating health issues on screen., Richard Terry, 2004/11/28
- Re: [Gnumed-devel] Aggregating health issues on screen., Karsten Hilbert, 2004/11/29
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextural Info, Richard Terry, 2004/11/29
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextural Info, Karsten Hilbert, 2004/11/29
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info, J Busser, 2004/11/30
- Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info, Karsten Hilbert, 2004/11/30
- Re: [Gnumed-devel] clin_health_issue - some thoughts, Karsten Hilbert, 2004/11/29
- Re: [Gnumed-devel] clin_health_issue - some thoughts,
Karsten Hilbert <=
- Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/24
Re: [Gnumed-devel] clin_health_issue - some thoughts, J Busser, 2004/11/17