Re: [Gnumed-devel] SOAP widget

[Ian Haywood]

On Tue, 13 Jul 2004 08:27:54 -0700
Jim Busser <address@hidden> wrote:

> > I can, however, include a header in the selection of text
> > using pos1/end and delete the header.
> 
> Each heading has, to its right, a white space character (space? tab?). 
> If I move the cursor there, I cannot backspace (delete) backwards, into 
> the heading but if I begin a text selection to the right of the white 
> space, I can select part or all of one or more headings, and delete 
> this selected text. Preservation of the headings might be critical to 
> proper functioning of any parsers, but there are probably limits on the 
> extent of protection that can be achieved against accidental deletion, 
> say from stray keystrokes.
True.
I have tried to prevent casual or accidental deletion of the headings, but
if someone deliberately tries to delete them, well that's different.
This prevents parsing the text into SOAP, if this happens my thinking would be 
to 
assume it is deliberate, and chuck the whole entry into an uncoded
clin_narrative entry. 
> It would be a shame to accidentally bugger up one's SOAP note with no 
> option but to have to cancel it, lose it all, and start over. 
IMHO a guding principle should be anythng the user types should be preserved
in the medical record, it just won't be tagged and organised as well if the 
user goes out
of their way to prevent this.
> Multi-stage "undo", not of course for records that have already been 
> flushed to disk, but at least for the text area in which one is working 
> would be nice --> add to a to-do list, or does anyone know it to not be 
> possible or feasible or desirable?
Is already implemented in the widget ;-) Try Ctrl-Z

> ENTER does the same for me, until I reach Plan, after which each press 
> of ENTER does create a new paragraph ("line").
This is intentional.
To me it natural to type "sore throat ENTER red tonsils ENTER tonsillitis ENTER 
penicillin ENTER"
Of course TAB can be bound to this action, or anything you like.

> Also, to be able to jump 
> directly to a particular editing area / plug-in, maybe based on 
> relative tab or screen position (1,2,3,4).
I quite like Richard's idea that editareas pop up dynamically when
certain keywords are typed. They probably shouldn't grab keyboard focus
(so you can ignore them and keep typing if you want, at which point they would 
politely vanish), 
but selectable by clicking or a key (TAB would be my choice, but I'm sure 
others would prefer something else)

I agree the editareas should still be accessible by other means. In 
my-not-so-humble-opinion,
this should be as toplevel notebook widgets, not tucked away under "Patient 
Details" where they'll never get used.
Navigating the notebook by keyboard is a must-have. A nice touch would be
to map the function keys (what else are we using them for?) to the matching
tab, so F1 to the leftmost, F2 to the next and so on. This is easy to remember, 
much better than arbitrary function mapping (F1 is for scripts, F2 for past 
history, etc.)

> > tabs are useful for structuring
> Some way to structure point form is useful. Maybe option-tab can insert 
> a suitable character unless unsupported by wxwidgets.
Unfortuately this is a source code editor we are using: special symbols and 
such are
completely off the menu. Same goes for embedding drawable diagrams in the text
[In Australia medical shorthand relies heavily on diagrams, particularly for
physical examination]
The minus sign "-" will have to do as a bullet point
(like a Wiki) 

Ian

-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgp3l7cNu6evZ.pgp
Description: PGP signature