gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Episode selection and creation


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Episode selection and creation
Date: Thu, 15 Sep 2005 14:54:09 +0200
User-agent: Mutt/1.5.9i

On Tue, Sep 13, 2005 at 10:39:27AM -0700, Jim Busser wrote:

> If the EMR tree by default opens with all subitem triangles "closed" 
> it will be an extra step for the user to have to open the triangles 
> to identify whether there exists an open episode.
I agree.

> Options would include
> - pre-opening the triangles for issues that have open episodes.
todo

> - appending to the issue line some indication (symbol or episode 
> name) the fact of an open episode
todo

> I guess closure of the 
> episode would be dated the current date/time because that is when the 
> judgement was made to close the episode.
I agree. This is currently assured at the database level by
the auditing trigger (it updates modified_when to now()).

> It should still be possible 
> to identify the date of the last encounter within the episode.
It is :-)

clin_encounter.modified_when or .last_affirmed

In fact, each and every clin_root_item has it's
modified_when time associated with it.

> I do have a question about the decision to close an open episode from 
> the tree. What if an open episode contains a plan that is incomplete? 
We are not into tracking medical decision/ outcomes/
completeness yet. IOW, we currently have no way to detect an
"incomplete" plan. So, whatever the user decides is to
happen will happen.

> How would one know, except by inspecting the content of the 
> encounters?
One would not.

> So if the episode perhaps *should* stay open, maybe its 
> better for the user (who declines to append) to have to make an 
> *informed* decision to close the episode, and maybe that can only 
> reasonably be done by viewing it. Depends if we have any agreement on 
> what it means to 'close" an episode.
To me it means the doctors decided (by means beyond my
*control*) that this episode is to go dormant.

> I think it should carry some 
> meaning such as "symptoms expected to resolve" (although you would 
> not know until later) or "care completed". A patient may have failed 
> to return within 90 days on account of personal problems and I am not 
> sure what is to be gained by having automatically "closed" the 
> episode, is there some inherent (or EMR performance-based) advantage 
> to closing it arbitrarily?
It is not closed arbitrarily. It is only closed when new
data is to be appended to the episode. Which mostly happens
when the patient re-presents. If the patient never comes
back and I don't manually go close his episodes on purpose
they stay open until the worlds tumble.

> Or to split some out e.g.
> - diabetes mellitus (control)
> - diabetes mellitus (foot care)
If I am a diabetic care center this may actually make sense.
In other settings it may not. Note that I could still tag
individual progress note lines with arbitrary markers (eg
foot care, eye care, glucose control) if I feel the need.

> While I do little primary care, I imagine that between followup 
> visits, phone management, patient-initiated visits, and dealing with 
> contacts from the diabetes centre and nurses plus lab results, there 
> might easily be a couple of entries per month just for diabetes so 
> over the course of  --- say --- 10 years there could be  2-3/mo x 
> 12mo/yr x 10 yrs = 240-360 entries. That is a lot.
Well, if that patient is under such regular care there will
be, say, 3 episodes per year, only one of them active. The
EMR tree (not the problem list) will then show 30 episodes
over the course of ten years - IF we choose to view that
level of detail. There may well be use for a view that
ignores episodes and only chronologically displays progress
notes for health issues. People are free to do so if it
makes sense. As Horst says: Allow structure but allow to
use it in a simplified (appropriate ?) form.

> So would there be a view that (for example) when dealing with this 
> patient's feet, looking back over their foot care (& ulcer) history 
> to review its course, the specialists involved, when were the most 
> recent contacts, there would be fewer visits to need to browse if 
> they were split out under
> - diabetes mellitus (foot care)
Well, the visits are most likely going to be aggregated in
some sort of, say, HTML under the episodes - or even the
issue itself. As needed.

> Would this also simplify the export (once we are able to do so) of a 
> *subset* of EMR information, say on one health issue, upon referral 
> to a specialist?
Yes. Improved data quality improves selectability.

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]