Re: [Gnumed-devel] The 1,2,3's of SOAP for multiple problems-2

[Richard Terry]

Karsten,

Beleive it or not, Guess how I enter stuff on my paper records, and have done 
for 22 years, yes, you guessed it:
1.
2.
3.

etc.

Yes, it has always worked well for me on paper. Computer wise it is very 
different. You may have the discipline to keep up such numbering in this 
environment but the point I was making is that 99% of others will not. A 
single mistake in data entry by the user will render any parser you make 
ineffective and lead to either confusion on the part of the software, or 
information parsed into the wrong part of a record.

gnuMed should not be designed for the half a dozen active developers. It 
should be taking into accound the lowest common denominator of user - ie the 
average doctor, the average GP, who is often semi-computer literate, let 
alone used to number ordering in their day.

I would urge you to actually put gnuMed stuff you are developing to the test 
in the clinical real-time, and I emphasise real-time, situation. But do so 
with a Zen 'beginners mind' - ie don't approach it with the attitude that 
what you have developed will work.

Note that I frequently do that - the tabbed mutliple SOAP concept being a 
classic. My gut reaction, because I think the sashed SOAP stuff sucks so much 
because it is so inelegant, was that it was a waste of time - yet I gave it a 
little thought - and an hours fiddling to write the code in between patients, 
and hey, I was impressed. Multiple SOAPs are really good - it is just how you 
implement them.

Also I keep on emphasising something which seems to be really lacking in 
gnuMed, that is an overview of the whole process, both visually and 
functionally. I'd like to see a screen dump of the Belgian project you 
mention  - so I can see it in the whole context of the medical record. I;ve 
emailed Marc to see if he would be kind enough to pass some on to me, if so 
I'll forward to the list.It may be fantastic - but integrating Carlos' design 
into screen real-estate on monitors most people are running (15") won't leave 
much space for anything else. I could be wrong - prove it to me by the 
integrated picture.

Regarding the linking of SOAP with multiple problems to a diagnosis. Why do 
you need to cleanly separate the thread. That is not what happens in the 
paper record. When you wish to review a thread - you scan back over multiple 
entries and your eye catches the words you want to link. Similarly, you can 
link any number of diagnoses to a single SOAP entry, and when you are 
reviewing this in a summary form, simply each consultation will be shown, 
just as it is on paper.

> > I personally still like the the idea of the user actively linking the
> > consutation to an existing or new problem at the bottom of the SOAP area
> > and having the multiple threads present in the same SOAP, which is much
> > more workable in actual use.
>
> But then one has no way of cleanly separating which thread belongs to
> which problem (which isn't obvious in some cases, yes) and this is
> very undesirable.
>
On Tue, 23 Nov 2004 07:02 am, Karsten Hilbert wrote:
> > The suggestion of the 1.2.3 below is UNWORKABLE.
>
> Well, it may be for you. It may be for the rest of the world.
> But is it not unworkable for me. I don't see a reason why
> GnuMed should not support this mode and if it is just for me
> (of course, I'll have to write the code myself then) - as long
> as it does not affect those parts of GnuMed that work for
> other people. Right ?
> Please don't think we are catching ideas out of thin air !
> The numbering thing DOES work. I do it daily. On paper.
>

> Also, the multisash-split soap idea didn't come out of
> nothing. A couple weeks ago I met Marc Verbeke, one of the
> authors of the Belgian EMR spec and and associate professor
> for Family Medicine at University of Gent, Belgium. He showed
> me an application he and a group of Belgian doctors use to
> record their episode related encounter data. It had that exact
> split-off-new-soap-widget functionality and it worked just
> fine. So there :-)
>
> > Before reading my criticism
> > please remember that there is a vast difference between half a dozen
> > enthusiasts using a program and REAL LIFE DOCTORS, many of whom cannot
> > type properly, and don't think in an ordered manner when it comes to data
> > entry.
>
> Sure, I don't have any grudge giving them something they *can*
> work with, too.
>
> > 1. It doesn't work in practice (I tried it for an hour - confusion)
>
> you forgot "doesn't work ... *for me*"
>
> > I wish you guys would actually try this in your day to day clinical
> > practice ie as you are working with real patients in real time.
>
> I don't just *try* the numbering. I *do* it. Albeit on paper.
> And tell you what my notes are far better than the other
> doctors' ones at that practice.
>
> > It is also useful to have gnumed running on your puter next to your
> > actual clinical software - that way you can duck and have a quick look at
> > it as you are actually using your existing clinical software - then 
> > keeping all these new ideas in mind - just have a quick think about
> > 'would this actually work now' - good example being Carlos's multiple
> > soap thingy - which I don't think is practical in its current format
>
> It is lilkely not the most practical but it doesn't
> conceptually involve any more switching between areas than the
> notebook. It's perhaps a bit less polished visually. But it
> should do the job somehow, for 0.1 at least.
>
> > - cause you lose everything else that is
> > important that you need to orient you to the patient.
>
> That is surely true. Your designs are usually nicely
> integrated.
>

> > Just as an aside - continuation of interrupted consultations. This one
> > struck me as I had a kid with quite severe tachpnoea and chest recession
> > which I wasn't sure was due to asthma or nasty infection. I opted for
> > asthma  and gave the kid a hefty dose of bronchodilator, but then had to
> > throw him out into the waiting room for it to work or not, and keep going
> > on with the consultation. A couple of patients later I reviewed the child
> > - tachpnoea dramatically settled etc - ie responded well - this
> > consultation should in fact be still active in gnumed - but put on hold.
> > Do we have such a mechanism in place?
>
> Yes. One might either just leave open one client waiting for
> the patient to be reassessed.
>
> Or else we do have some heuristics in place when loading a new
> patient. Eg. below a certain timespan we assume it's still the
> same encounter (4 hours). Above a threshold we assume a new
> encounter (6 hours). Inbetween we ask the user. We don't have
> a knob yet to allow the user to activate an older encounter as
> still being current (although the backend/middleware sure
> support that). Defaults kindly provided by Liz derived from
> service charge requirements.
>
> Karsten