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

[Ian Haywood]

On Thu, Nov 11, 2004 at 07:36:03PM +1100, Richard Terry 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.
> 
> Consulations were many and varied, ranging from simple I want a script for 
wow, real live testing. And only 24 hours since it was dumping core like
mad ;-)

> panamax 'Anything else', no doc, just that, to severe agitated depression, 
A word of explanation: the patient is a health-care card holder (i.e
welfare recipient) so they want paracetamol prescribed to obtain the
pharmaceutical subsidy, otherwise they pay full-price.
> 
> It soon became apparent to me that the SOAP concept just will not work at all 
> and I will expand on that in a minute. I don;t mean  the concept of the SOAP 
> style editor which Ian is kindly writing for us - it is brilliant (of course 
> my concept!!!!), and getting  better every day, but the concept of SOAP 
> itself for separating threads in data entry, I will justify this statement 
> below. I can remember the debates about this on the list, but must admit I 
> didn't involve myself a great deal in this. 
> 
> I ended up late in the day ringing up Malcolm Ireland. Some of you will 
<snip>
> I'm sure I could persuade him to reply and expand.
Can he offer any words of wisdom on the presentation of past history
data, particularly how a summary page should be structured, and
organising notes, given many (myself including) aren't sure tree widgets
are ideal, but can't think of anything better.

> Patient Request
> History Taken
> Clinical Findings
> Assessment
> Plan
This is also generally how I structure admission notes, with the
addition of "medications" and "past history".

I note the main difference is "S" is split into "Patient Request" and
"History Taken" [which implies a fifth clin_root_item type, say 'h' for
history taken]

> History Taken
> Clinical Findings
> Assessment
> Plan: Script Panamax
AFAIK we have always allowed for blank fields, in my current widget the
SOAP cycle is named after Assessment, if blank Subjective, then PLan,
then Objective.

> user  should be able to (cannot here in this simple example) link multiple 
> problems to the same consultation notes. If these are stored correctly, it 
> should be a simple manner of pulling out all consultations which were linked 
> to a particular problem and formatting them with html when you need to review 
> a particular problem.

Currently the backend schema allows each clinical record fragment 
(correspondes to each semicolon-delimited phrase in the SOAP widget)to be
linked to *one* episode. (but a consultation record contains muliple
fragments) I agree having seperate SOAP widgets for each problem is
clumsy, but to move to this model (where the whole consult is linked to
one or many problems) requires a big change in schema. 

Also, fragments (that is a single clinical sign, diagnosis, element
of history, plan action) *do* relate to a single problem, it would be
nice to be able to see only those parts of the narrative relating to a
problem (of course you can expand the view to give the whole consult
notes where a problem is involved).
Currently we have a drop-down list in the top right-hand corner that
lists the current active problems, whatever you do in the rest of gnumed
is recorded under that currently selected problem, the SOAP editor would
need to query this control at the completion of each semicolon-delimited
fragment (which is easy) to figure out what problem to record that
fragment under.

Of course we can reserve some function keys (say F2/F3) so the user can
quickly move between problems while typing.

Ian

pgpplpI8PvFwb.pgp
Description: PGP signature