gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Inf


From: Richard Terry
Subject: Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info
Date: Wed, 1 Dec 2004 08:56:30 +1100
User-agent: KMail/1.5.4

> Richard argues for a *single* SOAP area being attached to a
> list of problems regardless of which problems the individual
> items really belong to.
>... bla bla.... Richard also seems fine with *multiple* SOAP editing areas
> if they are put on a tabbed notebook

As I said on the list a few days ago, having actually used the editing areas
in multiple consultations, my preference is for starting with the undefined,
soap, and adding tabs as needed, either as a review of old problems, or new
problems (ie the multiple soap tabs) a la firefox browser approach, as per
the png's I showed on the list. This works reallly well. Having a pre-defined
number of SOAP's as per carolos's current implementation is wastful of screen
realestat.

> My suggestion was numbering with the episode numbering
> order arbitrarily created for this encounter. Richard
> denounced that as unworkable. Decide for yourself.
> Well, numbering wouldn't have any such amiguity. Entirely
> unnumbered soap widgets would belong to the "last active"
> problem. All other data can be traced to a number.

Again I'd urge to to try this in an actual SOAP control in real-time over
several days without prejudice. Karsten may be disciplined enough and capable
enought to number each episode but no other mere mortal doctors will be. Also
attatching an unnumbered SOAP episode to the last episode seems strange to
me.  Surely, the consultation contents just become part of the progress
notes. Why link it to a known problem when it hasn't been actively linked by
the doctor?

The major difficulty with your concepts of numbering problems is as I've
alluded to, how are you going to ensure the user conforms? Parsing will beome
a nightmare. Ordinary people just don't do that. On paper yes - we do it
every day because paper is well suited to that - but not electronically.

By the way, I'm having a focus group next week with our local GP on 'data
input paradigms in medical records', where I'm going to see what they think
works (won't tell them about gnuMed and SOAP until after they do all the
talking - and describe how they currently do it in their computer systems and
what the problems are).

A further question - have members moved any further to looking at SOAP vs the
other options I presented which seem to be more workable ie Patient History,
Doctor History, Clinical Findings, Assessment, Plan + link to diagnosis. I
know I keep labouring this point but I think it is really vital to move on
from a basic SOAP control to something that will actually work in clinical
practice - when consensus of those who have studied the SOAP method seems to
be that it hasn't proved practical in clinical experience.

Regards

Richard

> Richard argues for a *single* SOAP area being attached to a
> list of problems regardless of which problems the individual
> items really belong to.
>
> Richard also seems fine with *multiple* SOAP editing areas if
> they are put on a tabbed notebook. I would also be fine with
> that approach. It is likely we will implement this as a second
> approach after split sash.
>
> I also argued for a "numbered" *single* SOAP editing areas that
> allows to "mark" bits of data for specific problems by
> "numbering" them - much like your higlighting suggested below.
> Richard chimed in saying this would not work.
>
> > a) if it relates to only a single problem-episode, requires no
> > division into encountlets *but*
>
> This would work correctly in all of the above scenarios.
>
> > b) if, in the judgement of the doctor, the content is meaningfully /
> > usefully separable into encountlets --- each such "bit" able to be
> > "attached" to the pertinent problem --- this is *not mandatory*
> > however *is recommended (the only sensible way)* for any doctor who
> > desires to later assemble the pieces specific to such a "thread" to
> > be able to do so
>
> I do think we shouldn't have a vision lesser thatn this.
>
> > Alternatively some might think or favor that multiple SOAPlets be
> > created concurrently, in some combination of full or collapsed views,
>
> Which provides the same outcome in a different way.
>
> > with the doctor jumping back and forth among these SOAPlets as the
> > patient jumps around, but I worry this forces premature choices of
> > where the information "belongs".
>
> Well, any bit of data can be re-attached later if so desired.
>
> > Moreover there could be 2 new
> > problems happening but if the problems had not yet been created there
> > is a risk of circularity to the process. Lastly if I am busy I might
> > rather end the visit having captured my SOAP content but preferring a
> > while later (maybe after a few phone calls and a few patients) to
> > come back and further process what I was thinking.
>
> Sure, why not ?
>
> > So I would rather
> > have the option of collecting and caching content in a single area to
> > be able to attach pieces to problems as time and reason permit.
>
> If your mode of operation is thusly have the frontdesk staff
> create a new episode "today: <RFE>" at each and every
> encounter. Then write your SOAP notes attached to that
> episode. Whenever you feel like detailing further you can go
> back and sort into different episodes as wanted perhaps
> deleting the catch-all episode at the end. Some widgets might
> need to be written to efficiently support that but the backend
> doesn't have a problem with it.
>
> > - suppose we have within a SOAP  editing area several bullet points
> > and/or a few paragraphs
>
> My suggestion was numbering with the episode numbering
> order arbitrarily created for this encounter. Richard
> denounced that as unworkable. Decide for yourself.
>
> > - suppose portions are highlighted, or demarcated (whatever is the
> > method) thus denoting "encountlets" to be attached to each of
> > multiple specified problems (episodes)
>
> A different possible way of attaching within one SOAP widget.
>
> > -- what happens to any text that was *not* thus highlighted or
> > demarcated,
>
> Well, numbering wouldn't have any such amiguity. Entirely
> unnumbered soap widgets would belong to the "last active"
> problem. All other data can be traced to a number.
>
> > i.e. was the SOAP content being held only in memory, and
> > after the encountlet(s) are parsed off and processed, any other text
> > gets "dumped"?
>
> It would IMO get attached to the "last active" problem.
>
> > Or are we talking about *preserving* everything that
> > was in the SOAP editing area,
>
> Why of course.
>
> > and simply supporting the additional
> > functionality of *copying* bits into various problems
>
> If we so decide.
>
> > -- can the same bit of text be multipurposed into two separate problems?
>
> What for ? Technically it sure could.
>
> Karsten





reply via email to

[Prev in Thread] Current Thread [Next in Thread]