Re: [Gnumed-devel] Notes editor 0.4.6-1 feedback and suggestions

[Karsten Hilbert]

This discussion is good.

On Sun, Jun 21, 2009 at 12:28:10PM -0700, Jim Busser wrote:

>>> I very much think "Purpose" would be better but,

Purpose isn't bad.

> In the "Request" we have the possibility of this being "fed" by what the 
> reception would have input at the time of creating an appointment for a 
> patient.
I agree.

> A patient could advise the front desk that it was a private 
> matter or could specify a desire to come for a PAP test. Presumably the 
> reception staff is not making an encounter,

There is a misconception here. In GNUmed you don't (need to)
make a conscious decision to start or create an encounter.
Encounters just happen. Consider what actually happened in
the above scenario ? The encounter already takes place ! The
patient is talking to your reception staff ... She has
contact with the healthcare system ...

Only the type of contact is still to be decided upon.

We need to be careful to not confuse our encounter with what
insurance companies want us to believe happens in
healthcare: They only allow us to bill them for what *they*
think is a contact worthwhile paying for...

> or do we contemplate the 
> reception staff entering into the clinical SOAP rows administrative 
> records such as the fact of patients having telephoned and that the 
> patients left messages (sometimes with clinical content) for the doctor 
> to know?
Not necessarily. They may enter nothing but administrative
facts (say, demographics) if anything.

> Anyhow eventually we come into the current encounter and the patient may 
> advise "my private matter is that I am worried about a lump in my breast 
> but I do not know anyone (even the staff, who is my friend and  
> neighbour) to know." Even without sensitive matters, it is not uncommon 
> for an appointment to be booked for one reason but for additional matters 
> to be introduced wither by the patient or by the doctor into the visit.
+1

> I am therefore thinking that the text inside Reason could evolve within the 
> visit.

Absolutely.

> It could have begun "f/u ht" meaning I had wanted the patient to 
> return to reassess their blood pressure, however on arriving they 
> introduced that they need prescription refills for other things and also 
> had some blood in their stools. I would be inclined to add these into my 
> Reason so that I did not terminate the visit except deliberately deciding 
> if I would postpone any part of the assessment to a next visit. I would 
> modify the reason to say:
>       f/u ht (script refills, bloody stools?)

I agree.

> Into the notes editor I would raise the existing problem of  
> hypertension; a new editor would be open, into which I could capture  
> this complaint of bloody stools; and I am not sure how I would handle  
> this request for prescription renewals.
Personally I'd open notelet editors for each problem needing
a refill and write

soAp: normal
soaP: refill

for each

> For the hypertension I could  
> enter these into the "plan" but for other existing problems I am not  
> sure if I would raise them each into the editor to put the detail there. 
I would.

> I may rather not, because this would be a lot of work for a condition if 
> I am not reassessing it.
But you are, likely, aren't you ? You'll at least ask the
patient "so everything alright with ... so far ?", wouldn't
you ?

> However the presence of "script refills" in the 
> Reason is my reminder. Maybe it will be enough if my v6 simple medication 
> list remains accurate and we can separately consider if there is some 
> free text field/column where the renewal info could be entered.
There is/will be a comment field which certainly can be used
for that sort of thing but I'll be extra hesitant to add
prescription references into the first iteration of the
"current substance intake" handling.

> Next we come to the Summary. Each of the "Hypertension" and "Bloody  
> stools" problems has its own Assessment and there is no unifying  
> assessment over them... and if a third problem handled then even less is 
> achieved. I am wondering if the Summary may be better used to capture the 
> *context* of a visit such as "Back from Mexico" or "post-discharge 
> following anterior MI"

The Summary == Assessment Of Encounter = AOE certainly
requires some practice on the doctor's part to get right
(for her). It is a personal thing. It is a per-patient
thing. It is per-state-of-health thing. I believe it simply
takes practice. I also believe practicing that will hone our
clinical skills by making us think hard about the problems
at hand.

> Over to the EMR tree, to consider the utility of the encounter level  
> listings. I created a patient and within one (or maybe two?) encounters 
> created:
>       Elevated BP - hypertension? - Foundational issue
>               Episode: white coat effect vs white coat HT
>       Polymyalgia rheumatica - Foundational issue
>               Episode name: "PMR r/o GCA"
>       Headaches NYD (unattributed episode)
>       
> I made an AOE entry "steroid s/e, h/a persist, wants off ramipril pre- 
> travel to Turkey" and I now see in the left split:
>
>       Headaches NYD (unattributed episode)
>                       2009-06-19: steroid s/e, h/a persist, wants
>       Elevated BP - hypertension?
>               white coat effect vs white coat HT
>                       2009-06-19: steroid s/e, h/a persist, wants
>       Polymyalgia rheumatica
>               PMR r/o GCA
>                       2009-06-19: steroid s/e, h/a persist, wants

Hm, that's bad, I have to admit. You could

- enlarge the left split to show more
  - but that will show less on the right ...
- buy a larger LCD :-)
- hover over the encounter to take advantage of
  the tooltip showing better detail of the enounter
  metadata

I do think the AOE is of use - just think of encounters-only
listings - but maybe the EMR tree label selection logic
should be:

soAp row of episode for this encounter
  else AOE
    else RFE
      else type

(or just soAp else type, maybe)

> Therefore when I am later looking at the patient's Polymyalgia history, 
> it helps me to see she had steroid side effects as captured in the AOE 
> but the same AOE does not help me much. My suspicion is that in reviewing 
> the tree, a doctor would have one of two goals with respect to previously 
> documented encounters:
>
> 1. try to figure out which encounter likely contained the details of  
> interest or
I agree.

> 2. identify what synchronous (concurrent) issues were addressed in the 
> same encounter
Now for that a multi-problem AOE seems logical to me.

OTOH, the doctor is using the wrong tool (but we don't yet
have the tool she should use ;-)  She should use the tool
which lists:

encounter 1
 episode X1 in issue X
 episode Y1 in issue Y
encounter 2
 episode X1 in issue X
encounter 3
 episode X2 in issue X
encounter 4
 episode Y1 in issue Y

IOW, the continuity-of-care tree rather than the
state-of-health tree we got.

> In some cases the patient would be referring us to something they are  
> sure they had previously told us, or that we had advised them or had  
> told us that we planned to do. They may remind us that it was in a phone 
> call or that it had been in a visit or that it was something that Dr X 
> was going to discuss with us.
For that particular quest we should offer a total
longitudinal listing (we already do, it's the Journal View)
and a per-issue longitudinal listing (think all relevant
encounter data concatenated at the right when clicking on an
issue or episode node.

> AOE? Or else use the Summary / AOE to capture a context (like pre-Turkey) 
> although that is a different use of a summary than the AOE concept.
Maybe the Assessment term is wrong. In Richard's original
design I do think it was Summary of Encounter. That's also
why it is "Summary" in the widget ;-)

> The 
> AOE concept seems to apply when multiple problems are all related, rather 
> than unrelated, or else as an overall comment on the patient's health 
> (like "progressive decline, may need institutionalization")
The latter concept also seems a good use of it to me.

> rather than 
> something I have figured out how to use in an EMR tree where it is 
> re-demonstrated under multiple problems. ??
I do agree it warrants discussion to utilize the available
data more fully. Maybe using soAp (or soaP) is the way to
go. Ah, wait, not soaP, because that will contain potential
things about the *next* encounter :)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346