Re: [Gnumed-devel] emrjounalplugin.py comments further html work

[J Busser]

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.