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

[Karsten Hilbert]

On Wed, Sep 14, 2005 at 12:04:15AM -0700, Jim Busser 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. 
Almost the same effect (UI-wise) can be achieved by taking
the exact same design Horst shows here but replacing the
single free-text progress note input field with the
notebooked progress note input field we currently have in
GNUmed 0.1. One would then open new tabs when
double-clicking a problem. The drawback would be that one
would need to switch (inner) tabs when wanting to enter
notes for different episodes.

IOW the structure can be implanted into that design.

> Issue 1:
> ------
> Whether to support a separately & purely defined problem list (as 
> Horst seems to do)
Actually, this is quite possible with the current backend,
too. Just forget about health issues for the moment. Think
of episodes as problems - they are really pretty much the
same thing. You can define any number of them and have open
any number of them. You can name them any way you wish. You
can or cannot attach codes to the narrative if you so wish.

Such "problems" == episodes need to be clinically distinct
at all - nothing of that sort is enforced by the backend.

The health issues just provide a means to clinically
aggregate problems into larger groups.

> 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.
Same in GNUmed.

> And by extension when one or more problems are used 
> to tag a visit, the progress notes become retrievable by diagnostic 
> code.
No different here.

> This should not preclude attaching additional codes to a progress 
> note entry, e.g. to capture treatments administered.
It does not in GNUmed.

> 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.

I am not at all opposed to let people write a "dumbed down"
(or "different" if you prefer) interface for the backend if
they so wish. I could not care less. However, I am strongly
opposed to dumbing down the *backend* thereby precluding
ourselves of being able to take advantage of more structured
data should we chose to employ it.

The one point I do not have an answer for yet given the
current backend is that, indeed, GP medicine seems to
warrant linking some progress note snippets to more than one
"problem" (= episode name). I am thinking hard currently how
to best accommodate this. I think Richard, Horst, you et al
do have a point there. I do, of course, recall times when it
felt natural to think of some piece of narrative to belong
to several problems at once in my very practicing medicine.

> 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.
Now, you always find the perfect use case for shaking our
foundations :-)

This case lends itself quite well to the current approach:

- have a table clin_aux_narr2epi which allows for additional
  episodes/problems to be linked to this clin_root_item
  (eg clin_medication)

- make the prescription widget allow to select further
  episodes/problems to be attached

- set clin_root_item.fk_episode to whatever episode/problem
  the prescription happened to be triggered under

- the actual medication row would thus be linked to several
  episodes/problems, however, the prescription widget could
  automatically place identical cues into the progress notes
  for each of the episodes/problems

Other cases could be handled similarly. Progress note
widgets could have a field "Also link to".

> 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
It could be - GUI wise. It should not be backend-wise
because that is not necessary anymore.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346