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

[Karsten Hilbert]

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

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

> 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
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346