Re: [Gnumed-devel] SOAP widget navigation

[Jim Busser]

I am wondering how the SOAP widget might function before saving data, 
as well as in a reviewing and editing (auditing) capacity.

So far Richard has suggested that within an encounter, multiple draft 
RFEs with draft SOAP/AOE elements could co-exist as a list with each 
ideally expressed in a condensed, single-line format:

Hypertension:S:request BP check..O:.130/80......A..good control.... 
P...script.
URTI: S.cough,runny nose.....O.NAD..A:Viral URTI...P:  Symptomatic etc
Undiagnosed: S vaguely unwell.....0:nil to find A ?diagnosis P.FBC, 
ESR, etc..

reference: 
http://lists.gnu.org/archive/html/gnumed-devel/2004-07/msg00007.html

At any one time, any one could be easily brought up into the on-screen 
edit area for further input or modification. This would permit easy 
switching to whichever note that the data to be input warrants. Is this 
multi-problem functionality targeted for 0.1, or should the plan for 
0.1 be constrained to single-problem encounters?

After we have support for multi-problem encounters, an elegant function 
(post 0.1) would support drag-and-drop where the content in one note, 
where it is decided to pertain better to one of the other pending 
notes, could be dropped onto it and, based on its origin from any one 
SOAP/AOE section, be appended to the corresponding section. The 
original note might remain in the edit area or, if desired, we could 
have the destination note respond by jumping up into the edit area.

I don't know whether during creation of the SOAP notes, and while they 
are being worked on, the rows will exist only in memory, or will have 
their content written immediately, or cached at intervals decided by 
postgres, into table records? Are they then immediately subject to 
audit requirements? If we are willing to tolerate this limitation for 
0.1 -- choosing to delay until post 0.1 Horst's limbo proposal -- will 
audit functions be invisible to the user?

I did not see in the schema an an audit_explanation/comment/annotation 
field into which the user can be permitted or forced to annotate a 
source or reason. If it was desired to require or at least support this 
data element, I was wondering whether as part of a SOAP edit/audit 
function, we could activate a previously written SOAP entry such as the 
example I gave earlier today, and support an in-line audit annotation 
within square brackets or braces so:

Original:

S: sore throat 3d, mild pain on swallow, no nose, ear Sx, no cough

Modified:

S: sore throat 7d, no fever {patient correction/addition}, mild pain on 
swallow, no nose, ear Sx, no cough

Programming could identify that the content had been changed and/or the 
parser could assume it from user input of the audit annotation 
characters. These characters could be allowed to be input anywhere 
inside the element, for example I could have inserted at the end of the 
Soap line. Upon committing, the content could then be invisibly written 
into the audit_annotation for me. I suppose it would be handy for any 
audit information to be displayed within the SOAP line maybe using the 
same convention i.e. displaying it within brackets or braces, so that 
the user (maybe a covering doctor) can know whether it might have 
changed since they last viewed it. If there is yet a further change to 
be made, the audit annotation could be revised or replaced to create 
the newest version. It may or may not be feasible/desirable to make the 
audit markers unalterable in the same way that we wish the SOAP labels 
to be (relatively) alterable within the edit area.