[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day
From: |
J Busser |
Subject: |
Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day |
Date: |
Fri, 12 Nov 2004 02:10:23 -0800 |
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.
Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day in consultations, Karsten Hilbert, 2004/11/16
Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day in consultations, Karsten Hilbert, 2004/11/11
Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day,
J Busser <=