[Top][All Lists]
[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
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, (continued)
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Karsten Hilbert, 2005/09/09
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Ian Haywood, 2005/09/09
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Karsten Hilbert, 2005/09/11
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Karsten Hilbert, 2005/09/11
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Ian Haywood, 2005/09/11
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Karsten Hilbert, 2005/09/12
- [Gnumed-devel] Episode selection and creation (was: Gnumed on Windows: the pain of pyPgSQL), Ian Haywood, 2005/09/12
- Re: [Gnumed-devel] Episode selection and creation, J Busser, 2005/09/13
- Re: [Gnumed-devel] Episode selection and creation, Ian Haywood, 2005/09/13
- Re: [Gnumed-devel] Episode selection and creation, Karsten Hilbert, 2005/09/17
- Re: [Gnumed-devel] Episode selection and creation,
Karsten Hilbert <=
- Re: [Gnumed-devel] Episode selection and creation (was: Gnumed on Windows: the pain of pyPgSQL), Karsten Hilbert, 2005/09/15
- Re: [Gnumed-devel] Episode selection and creation (was: Gnumed on Windows: the pain of pyPgSQL), Karsten Hilbert, 2005/09/15
Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Tim Churches, 2005/09/09
Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Karsten Hilbert, 2005/09/11
Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Tim Churches, 2005/09/11
Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Karsten Hilbert, 2005/09/12
Message not available