gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Busser
Subject: Re: [Gnumed-devel] Notes editor 0.4.6-1 feedback and suggestions
Date: Sun, 21 Jun 2009 12:28:10 -0700

On 20-Jun-09, at 1:42 PM, Karsten Hilbert wrote:

2) "Request" ... is somewhat ambiguous as, in english unfortunately, we 

have the problem when the same word is sometimes a noun:

request as "purpose of encounter" (noun) -- which is what we intend vs.

request as "(now) ask for something" (verb)


Ah, I see. In German it'd be a bit clearer because nouns

would be spelled uppercase as opposed to verbs.


I very much think "Purpose" would be better but, if it is desirable that 

this not be just one arbitrary GNUmedder opinion shall I ask a few doctor 

colleagues their views?

Sure, great !  Show them a screenshot, perhaps ?


Help me further about "Request" and also "Summary (AOE)" as these may also assist my question about what to list in the left side of the EMR tree at the encounter level (encounter type vs AOE vs something else).

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. 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, 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?

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. I am therefore thinking that the text inside Reason could evolve within the visit. 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?)

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. 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 may rather not, because this would be a lot of work for a condition if I am not reassessing it. 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.

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"

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

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
2. identify what synchronous (concurrent) issues were addressed in the same encounter

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. That is the origin of my idea that in the tree it may be better to concatenate, to the right of the date of the encounter, the type of encounter (in praxis, phone) or maybe the initial 40 characters of the Assessment or Plan of the *problem* rather than the 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. 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") rather than something I have figured out how to use in an EMR tree where it is re-demonstrated under multiple problems. ??

reply via email to

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