[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] emrjounalplugin.py comments further html work
From: |
J Busser |
Subject: |
Re: [Gnumed-devel] emrjounalplugin.py comments further html work |
Date: |
Wed, 14 Sep 2005 00:04:15 -0700 |
At 10:59 PM +0000 9/13/05, Horst Herb wrote:
My "compromise" is a single text box for entering unstructured text but with
the provision for tagging text in order to provide some sort of structure and
searchability
...
By default I will always have the previous progress note in view for
reference, but a single click (sort by problem) will default to the last
progress note tagged with the current problem (if current problem already
set)
It is hard *not* to like what Horst has shown in terms of usability.
So I wonder if I can bridge some understanding between this, and what
Karsten sought to structure.
There seem to be two issues:
Issue 1:
------
Whether to support a separately & purely defined problem list (as
Horst seems to do), or whether to define problems functionally as a
subset of health issues i.e. those that remain after filtering out
health issues that are inactive along with any closed episodes that
do not remain clinically important.
Interestingly Karsten, in an old thread at gnumed.org, referenced the
following which contains a section 3 screens down called "is the end
of the problem list - no" to which I will refer people:
http://web.archive.org/web/20010305030646/http%3a//phcsg.ncl.ac.uk/conferences/cambridge1998/westerhof.htm
Horst's approach could permit the problem (no matter what language
was used to name it, free-text) to be attached to one (or even more)
diagnostic codes. And by extension when one or more problems are used
to tag a visit, the progress notes become retrievable by diagnostic
code.
This should not preclude attaching additional codes to a progress
note entry, e.g. to capture treatments administered.
Issue 2:
------
The pros and cons of *partitioning* the data contained within any one
visit (encounter) into parts each attached to the "owning" issue.
There may be a *design tension* here between what's advocated by
technically correct designers, who strive to maximize the exactness
or precision of a data relationship versus what is "good enough" and
much more satisfactory to get the "work" done.
So if at a visit a patient was initiated on an angiotensin converting
enzyme inhibitor at a visit where diabetes, hypertension and heart
failure were pertinent, does it matter which one (or more) problems
were the "indication". Even if we care (because we might) is there
some way to capture this other than by partitioning the contents of
the note into separate problems? After all, maybe the drug is
selected to treat all three (supposing they have proteinuria [setting
aside if that should be separate]) but we certainly don't want to
have to repeat the drug three times, once in each partition.
There seems always pressure from those who want to *use* the data to
(always make someone else) input it into a system. The value is
achieved through a cost transfer of labor (to the person doing the
input). It is the same phenomenon by which my hospital's IT
department endorsed a vendor's migration from client to web browser
solution... makes IT department's job a lot easier though it is hell
and much extra work for the doctors and nurses.
Anyhow I could be open to a backend that supports those who want to
do the extra work of splitting *but* can this also accommodate the
single-SOAP per visit design? I am wondering whether single-SOAP is
the way to start (assuming it can be made to work with the present
backend plus or minus a need to add problem lists) and then leaving
until later a required use-case for splitting. Splitting would in
some cases be easy, but when bits of SOAP data apply to MORE than one
problem it will drive me a bit nuts to have to choose the health
issue into which to parse it, or to have to repeat the content when
our goal is probably to be reductionist.
- [Gnumed-devel] emrjounalplugin.py comments further html work, Richard Terry, 2005/09/13
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, J Busser, 2005/09/13
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Richard Terry, 2005/09/13
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Horst Herb, 2005/09/14
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Karsten Hilbert, 2005/09/19
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Ian Haywood, 2005/09/19
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Karsten Hilbert, 2005/09/21
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Karsten Hilbert, 2005/09/19
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Karsten Hilbert, 2005/09/18
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Richard Terry, 2005/09/18
- Re: [Gnumed-devel] emrjounalplugin.py comments further html work, Horst Herb, 2005/09/18