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

[Richard Terry]

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
>