gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] need assessment from fellow clinicians


From: Richard Terry
Subject: Re: [Gnumed-devel] need assessment from fellow clinicians
Date: Wed, 30 Jun 2004 15:26:41 +1000
User-agent: Mozilla Thunderbird 0.6 (X11/20040503)

Some rough thoughts about how I record an encounter.

1) The presentation may be from the existing active/inactive problem list eg Hypertension, hence in the medical records one needs to be able to select the problem from this list, and add SOAP notes regarding it (even if some components of SOAP may not be filled in), so that a later time all records pertinant to that problem may be viewed sequentially, even where they were only a part of a multi-problem encounter. 2) The presentation is a new well defined symptom/symptom group with a defined diagnosis at the end (eg URTI) which will not be a significant problem long term. 3) The presentation is well defined and will be a significant problem long term eg MI/IHD and the problem is added to the long term list of problems 4) The presentation is undifferentiated and no diagnosis is reached at end of the consultation - This one is should probably still be recorded in SOAP/extended text notes/ but the difficulty is how to tag it in the records. If may later have a diagnosis attatched to it, eg ill defined upper abdominal pains may later be diganosed as gall stones/peptic ulcer etc. 5) Some consultations as simple narratives eg phone consultation with/from patient without an attatched problem but still have to be recorded.

If the patient comes in with single or multiple problems, my writing goes something like this although I don't write the SOAP in the columns. remembering that SOAP stands for Subjective (patients complaints) Objective (our findings) Assessment (what we find) Plans (what to do). This fits the editing area concept brilliantly as intelligence can be linked to each of the lines to supply an appropriate list of pop up words, matching the users input, but contexturally according to the line one is on.

1)Complaints of URTI
   - sore throat, runny nose, cough, non productive
    - 0/e:red throat, bulging left drum
    - Dx = URTI with ROM
    - Rx - Amoxycillin/analgesia, review if needed

   ie. many of these encounters fit into the SOAP format
2)Hypertension
This even fits the soap, the S is implied (or requested)
     S: patient requests BP review or BP review due
      O: 120/70
      A: (may contain commment if bad eg poor control)
       P script atenolol 50 * 1/day

3)Abdominal pains
S: epigastric, related to meals, r/b antacids O: vague tenderness
      A:?peptic ulcer
     P: ppi, arrange gastroscopy >referral Dr Blogs etc

I also like the concept of
Beratungsergebnis or Assessment of Encounter, which is what I use all the time.
I call this a 'summary of the consultation", and it may go something like

Abdominal pains ?diagnosis, if doesn't settle > review or Abdominal pains ?gall stones > abdominal u/s review after

Or Leg swelling > probably DVT > doppler > review today etc
======================================================================================
ie the AOE should be a tag linked to the whole of the particular consultation 
episode
======================================================================================
and one should be able to review sequential AOE's like one would review a flow 
diagram.

Whilst on the subject, any of these presentations fits well into the editing area concept. I've had further thoughts on the subject of the editing area which I think I was spurred by Horsts simplistic data input design.

As I mentioned in a previous post, I think we could incorporate all the benefits of the defined editing area into a smart text editor by modifiying one of the existing wx controls such that we had a more text like page in front of us, but with the labels of the editing area actually part of the editor but 'out of bounds' to the user.

Ie say we had:

----------------------------------------------------------------
Subjective  : complaints of earache, fever, sore throat
Objective   : red drum, perforated with pus in ear canal
Assessment:
Plan
-----------------------------------------------------------------
If the user clicks on this area, but the cursor is over any of these text entries, this area is out of bounds, and the cursor is re-directed to be adjacent to the start of the line adjacent to the word. As the user typed, then the editor could also take care of auto-expanding the available space: e.g the above looks like below as an extra line is added as the user types. That way we would not be constrained by a set size of text box.

----------------------------------------------------------------
Subjective  : complaints of earache, fever, sore throat
                  rash on legs
Objective   : red drum, perforated with pus in ear canal
                  pus on tonsils, temp = 38deg, macular rash
                  on limbs.
Assessment:
Plan
-------------------------------------------------------------------
Coding such an editor is not that hard. I wrote one in FORTH many years ago - a text mode text and graphics editor, which I used to create binary images of popup windows to write back to the screen (this was before windows itself came on the scene!). There are existing examples of editors in the wxPython world we could modify. If we combined such a design with the popup phrase wheel we could get the best of both worlds, as the 'tags', (here Subjective, Objective etc) could be user-added with function/control keys as one typed, giving a very flexible record entry system, once which I suspect Horst would be more at home with than the current editing-area concept. Another advantage of this is a huge saving in screen display area, which could then be used more efficiently for other things.

If anyone who has the coding skills to modify such an editor wanted to step forward, I'd be happy to help them conceptualise it.

Anyway, I'm not sure if this adds anything to the discuss, but don't forget I like the

Beratungsanla├č" concept and think it should be included.

Regards

richard




Karsten Hilbert wrote:

Hi all,

I have been thinking on how to best get the wildly overlapping
concepts of "Assessment" (soAp), "active problem" (aP), and
"diagnosis" (Dx) (medical, not billing) under control and
aligned. I think I have come up with a plan but need feedback.

We probably all agree upon the fact that in primary care there
is the useful concept of Reason for Encounter (Reason Visit
Care, for them Americans) - RFE (German "Beratungsanla├č").

soAp can be anything from "Borreliosis - positive serology"
(hard-n-fast diagnosis) to "acute abdomen, seriously ill,
requiring investigation" (rather vague - but still useful ! -
narrated assessment).

Dx *should* be a well-established medical diagnosis.

aP can be any of the above. The difference to soAp would be
that aP does not contain explanatory statements but rather
treats free-text assessments as if they were diagnosis (eg.
"acute abdomen").

German literature on the subject talks about a
"Beratungsergebnis" - the verbalized outcome of an encounter
as agreed upon by patient and provider. I think this captures
all of the above quite well and we would call it "Assessment
of Encounter" - AOE.

Now, how would we relate the AOE to other concepts ?

- Each encounter may have several RFEs.
- Each episode may have several successively refined RFEs some
 of which may simply be "followup *" where * is the RFE of
 the previous encounter. (Should this be free text or do we
 allow for a is_followup::boolean field in the tables ?)
- The latest AOE per episode is regarded an aP. AOEs may be
 tagged "permanently relevant" such that they stay listed as
 aPs even when their episode is no longer active (what that
 means, semantically, needs to be investigated, perhaps a
 timeout will do).
- There should be exactly one AOE per episode-encounter-combo,
 eg each episode touched in an encounter should have *one* AOE
 (there may be several RFEs, though per episode-encounter-combo).
- "coded_diagnosis" rows may link to AOEs which makes them a
 diagnosis should any code care to look at the link between the
 two. Another option would be to have a field "certainty"
 right in the AOE table -- if we can agree upon a
 classification. The German literature talks about "symptom",
 "group-of-symptoms", "syndrome", and "diagnosis". I am fine
 with this but I realize this may be debatable in other
 societies.

So, in conclusion, soAp is the narrated case assessment per
encounter. An AOE is the gist thereof in one catchy phrase. aP
is the latest-and-greatest of them AOEs across all encounters
per one episode. Dx is likely to appear as one of the last
AOEs per episode if and when a scientific medical diagnosis
has been established.

Phew.

Does that make sense ?

Karsten





reply via email to

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