[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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]