Re: [Gnumed-devel] more comments....I tried it all day in consultations

[Richard Terry]

Another point about this it that although I think we should allow multiple 
porblems to be encountered via the soap control, there is absolutely nothing 
stopping somone hell bent on sub-splitting up all the patients problems to 
enforce a per-problem use of the same control. It really is very flexible.

Also I agree with the comments about the flexibility of Ian's code - I 
commented on this to Ian - I always found with VB that when I had/or was 
close to the solution the code was simple/logical/non-hacked. With his 
current solution it is really easy to add any number of headings/sub editors 
etc. Really good.

Perhaps we could vote to change the basic SOAP headings to the ones which seem 
to work.

Another comment (from something syan said), there is absolutely not reason - 
and in fact this should be implemented, that the popup editors shouldn't 
appear (say) in the history taken section. ie As you take a general history 
you invoke the ph editor which pops up, if the patient is allergic - then up 
pops the allergy subeditor. Of course, upon saving the SOAP stuff, the system 
as well as keeping the entire SOAP control contents to be part of the 
progress notes, also sub-splits out the past history items into the 
appropriate table.

Also I've lots of comments on the progress note question, but I'll post those 
in a separate heading. Note of course, that each SOAP entry collection is 
actually a progress note section.

Regards

richard

On Fri, 12 Nov 2004 04:29 am, Karsten Hilbert wrote:
> > I spent today using the SOAP2.py editor to enter all my consultations,
> > some 30 of them, telling the patients I was testing 'someones' concept of
> > data entry.
>
> Tell you what, you are the man !
>
> > Also as we all
> > know most of these patients come in with multiple complaints and it is
> > simply not easy/quick to split off all the threads into different soap
> > notes. They start one thing - minutes later change to another, then
> > revert to the first again etc. We all know what too well.
>
> Agree.
>
> Today I discussed this a bit with Ian on IRC. In my practice I
> usually number the RFEs, then add those numbers to the things
> the patient is telling me. This, BTW, is also a clinical
> quality improvement tool (at least within one encounter) - I
> don't forget to follow up on something the patient said
> earlier). It does happen that those numbers aren't written
> down in order as the consultation progresses. A machine will
> be able to sort that out later, paper won't. Note that those
> numbers are volatile - I don't keep them for the next
> encounter. I will re-number RFEs as the patient mentions them
> at the next visit. Same goes for our "SOAP" widget - no need
> to keep the numbers. We could pregenerate the numbers, too,
> eg. number the known problems on the spot and display the
> numbered list while entering the SOAP notes. And after
> parsing/saving immediately forget the numbering again until
> the next incantation of the SOAP widget.
>
> > What became very clear to me is that it
> > will not be possible (and see comments below) to sub-split all problems
> > into individual soap notes and still have a workable system.
>
> I suspect you are correct. Nonetheless, a multiple-SOAPs
> widget is useful as it offers an *implemented* way of doing
> business.
>
> > His opinion and comments were as follows. SOAP has been extensively
> > researched and seems to have been discarded as a data entry system, as it
> > does not work in practice. He also acknowledged just what I found today -
> > that the only thing that works is to enter all the various problems into
> > the same record of the consultation.
>
> Which is NOT a solution for a problem related to the SOAP
> concept in itself. It is a solution to being unable to find an
> efficient way for entering data into per-problem soap widgets.
> Given his expertise I am inclined to trust that there isn't
> really a good way to do it.
>
> > By mid afternoon, I had found the headings:
>
> Thank $DEITY SOAP2 is intended to be header-agnostic, eg. one
> can name the headers any way they like. And change the humber
> of headings, too ! (Does this still hold true, Ian ?) It is
> then just a matter of teaching the post-OK parser how to treat
> the various parts of the returned dict. I suppose it would
> help to attach SOAP type codes to the headings passed to
> __init__() so the parser can just depend on that with the
> output.
>
> > Patient Request
>
> == RFE (S)
>
> > History Taken
>
> == Subjective (S)
>
> > Clinical Findings
>
> == Objective (O)
>
> > Assessment
>
> == A
>
> > Plan
>
> == P
>
> So, nothing new there apart from better names. And fully
> supportable with current code. Also, fully storable in the
> current backend. Precisely this we already had/have - we just
> called it
>
> RFE
> Subjective
> Objective
> Assessment
> Plan
>
> > Worked well. (I personally would also had a Summary of entire
> > consultation)
>
> This is certainly supportable should you one day decide to
> use GnuMed and tell me/us to implement it.
>
> > I commented to him that in a large number of situations it wasn't
> > possible to enter data in many of the fields for example as per this
> > today (see the pngs), not atypical:
>
> Not at all a problem for GnuMed. And with Ian's
> shrinking/expanding widgets not a screen real estate hog
> either.
>
> > In regard to how to link a particular consultation in a progress notes to
> > a problem - there are many ways, and I note recent comments and debate on
> > this.
>
> ...
>
> > In the SOAP version below, I've added a simple combo box to
> > allow the consulation to be linked to an existing problem, additionally 
> > the user  should be able to (cannot here in this simple example) link
> > multiple problems to the same consultation notes.
>
> This introduces artificial ambiguity which we should like to
> avoid if we at all can. We will always have ambiguity but we
> need to avoid creating more of it due to technical
> deficiencies. A consultation often inherently is about several
> problems. One would want to link any part to the *appropriate*
> problem.
>
> > If these are stored correctly
>
> Given the above it is impossible the store them semantically
> correct. Technically correct is a matter of Of Course !
>
> I think it is a good idea to use an encounter list displaying
> the Assessments. However, this is *separate* from the SOAP
> widget in itself and should be done inside the enclosing
> widget IMO.
>
> Karsten