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

[J Busser]

At 7:36 PM +1100 11/11/04, Richard Terry wrote:
> 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.

This challenge to deal with what patients tell us, and/or ask us, 
and/or want from us, especially when they are multiple items jumbled 
together, is the utmost test of design. It affects not only how (and 
where) new data is entered, but also the competing needs between 
entering information and keeping in view contextual, 
helpfully-presented other patient (or reference) information.

As I too try to think my way through this further, I was going to 
change the subject of this email to "another shot at GUI 
considerations" - if people think this worth responding to, maybe 
make such a change in the reply?

> there are only two consistencies that matter in any written medical record
> - what the patient requests, and what the doctor did

So we must
- record new information and the authorization / initiation of actions,
***but*** to do this we must also
- view, navigate among -- and maybe amend/update -- file information

So within an encounter, key factors become
1) what the patient was *expected" to want
2) what the patient *actually* wanted
3) what I *planned* to do
4) what I *actually* do

elaborating:
1) what the patient was *expected" to want would normally come from 
their "reason for encounter" (RFE)
2) what the patient *actually* wanted only becomes known during the 
encounter, it may be a correction and/or addition to the RFE. This 
refinement of what becomes eventually the final actual patient agenda 
may not be complete until the end of the encounter.
3) anything more I *planned* to "do" (could be reassess a problem) 
could come from a combination of the scratch pad; from a to-do list 
if and when there is support for something like it (other than the 
scratch pad); and/or from periodic health exam items that are 
pre-scheduled; or as other tasks "prescribed" by a clinical decision 
support system (maybe the future Egadss) if enabled into gnumed
4) anything more I *decided/realized* I needed to do would come from 
some combination of assessing the patient for their 
complaint(s)/request(s) as well as anything more that I realize while 
scanning the record, for example noting that medications may need to 
be re-ordered or need changing

Within a consultation, as patients "add" to the reasons that they are 
seeing me, or mention in passing key past or other history, I jot 
such pieces directly into the pertinent area on a paper form (for as 
a consultant, my patients are often "new" to me). But on a computer, 
there are several options.

a) "move/jump" the cursor to a different screen area to achieve the 
same effect as on paper i.e. to put the data somewhere outside the 
"narrative" portion of the backend - in order to do this, such 
"areas" would ideally be in view and quickly accessible but would 
even so be prone to jerkiness as the patient shifts to yet some other 
content, I would fear for the quality of whatever rapport had been 
established

b) *not* moving the cursor, instead:
   i) enter a mode in which the input text/string continues in place, 
but is visually indicated as being tagged to be either moved or, 
better (?), copied into the pertinent "other section" or
  ii) the input text/string continues in place, but is able at any 
time to have a portion selected and "tagged" as pertinent to another 
standard "section".

In terms of data input it would seem least disruptive to allow *all* 
of what a patient says to go into Richard's "History taken" area. 
Where desirable, drag and drop could aid to re-organize any info that 
had been taken down as a jumble. Or am I wrong that most people see 
themselves moving the cursor always as the patient speaks and jumps 
around, and/or as you realize, after leaving a complaint, that an 
important question must still be asked?

Does a clearer separation need to be made over which (or all) history 
would be entered in the history, and which information be 
tagged/copied into other parts of the backend, and which history info 
be entered PURELY into non-narrative parts of the backend?

I will also think further on how focusing on "key factors" 1-4 might 
affect design.