[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Episode selection and creation
From: |
J Busser |
Subject: |
Re: [Gnumed-devel] Episode selection and creation |
Date: |
Tue, 13 Sep 2005 10:39:27 -0700 |
At 8:02 AM +1000 9/13/05, Ian Haywood wrote:
Karsten Hilbert wrote:
On Mon, Sep 12, 2005 at 07:42:41AM +1000, Ian Haywood wrote:
What should happen if the user had selected a health issue
from the problem list but which already has an open episode
of age < 90 days ? I think we then need to ask the user for
guidance, no ?
IMHO I would like it silently added to the open episode.
Sounds OK to me. What about the *name* of the episode ? The
> user may wonder how to find his notes ...
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.
Options would include
- pre-opening the triangles for issues that have open episodes.
- appending to the issue line some indication (symbol or episode
name) the fact of an open episode
- give no indication, however when a user clicks on an issue
---> if there is no open episode, start one BUT
---> if an open episode exists,
-------> either default the new encounter to belong to the open episode or
-------> notify the user "Append to (open) episode "<Episode name>
initiated <date>, last encountered <date>?" and if the user answers
"no" then close the episode and begin another. 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. It should still be possible
to identify the date of the last encounter within the episode.
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?
How would one know, except by inspecting the content of the
encounters? 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. 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?
I also have a question about a constraint to have only one open
episode. I don't disagree but it does have consequences. It means
that a patient who, within their diabetes, has active problems of
poor control and foot ailments, they cannot have one open episode of
each inside the top-level issue of diabetes. So there would be two
choices, correct? Bury/blend every aspect of diabetes care inside
diabetes "episodes" some of which will pertain to education, some of
which will pertain to hypoglycemia, some to weight loss, some to
diet, some to foot care, and many to a combination of two of these.
Or to split some out e.g.
- diabetes mellitus (control)
- diabetes mellitus (foot care)
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.
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)
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?
- [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, ihaywood, 2005/09/09
- Re: [Gnumed-devel] Gnumed on Windows: the pain of pyPgSQL, Horst Herb, 2005/09/09
- 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/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 <=
- 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, 2005/09/17
- 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