Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day in consultations

[Karsten Hilbert]

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