Re: [Gnumed-devel] emrjounalplugin.py comments further html work

[Richard Terry]

James,

Regarding your comments on complexity I agree we have to look beyond the 
single encounter visit. 
As you mentioned, having to input SOAP notes as we do currently, we end up 
with

 S - Having trouble adhering to diet. Checking ~ 2x daily, staggered
 times, 9-13 mmol/L
 O - Last A1C 0.09% ( is it under O we would comment on test results,
 or under A?)
 A - Agrees to incr meds while continuing effort at wt loss (Duh! <> A)
 P - Incr metformin 500->850mg bid
       (using whatever trigger text would activate the medication list)

 S - Noted slight drainage on socks past 3 days. No
 pain/red/fever/trauma but new shoes 7d ago.
 O - (Details of exam)
 A - Whatever
 P - Whatever

The essence of the encounter which we as a doctor immediately grasp is that of  
poor diabetic control - ie the patient comes in, maybe for something else, we 
note his last hba1c was 11.5, and we tend to think in terms of what are we 
going to do about this problem, not particularly what the presenting symptom 
is. The difficulty becomes, how to translate this to the computer - if you 
enforce a structured consultation it is always going to be difficult to enter 
via a SOAP note because we don't always think in that order.

If you simply have a past history list, select 'diabetes' and add clinical 
notes, you and I would probably end up with something you listed above, yet 
written more like what I"ve shown below: - note here this makes sense to us 
without lables (including incorrectly entered data such as you have put above 
in the Assessment field - which is really part of the plan, whears the 
assessment would have been 'poor control'.
 

Diabetes
=====
 - poor control:
        Having trouble adhering to diet. Checking ~ 2x daily, staggered
        times, 9-13 mmol/L
        last A1C 0.09% ( is it under O we would comment on test results,
        under A?)
        Agrees to incr meds while continuing effort at wt loss
        Incr metformin 500->850mg bid

- diabetes mellitus (foot care)
        Noted slight drainage on socks past 3 days. No
        pain/red/fever/trauma but new shoes 7d ago.
        (Details of exam)
        Assement Whatever
        Plan Whatever'

Sure the computer could in some instances generate a format that makes sense, 
but I have a horrible increasing suspicion the more and more I play with this 
(which BTW I do constantly day after day in/in between real consultations 
testing how they would fit), that trying to enter data in this structured way 
is a ***no goer*** in the long term, and will lead to enormous frustration 
for the doctor, and ambiguity to anyone else reading the notes, and worse 
than that, doctors eventually entering data in a format which they find easy, 
or that they know the computer will 'make sense of' but not real data in 
their words.

Now, gasp, sigh, but please all take this in:

The more and more I play with this type of data entry in my consultations, , 
the more I'm coming around to Malcom Irelands view (and I suspect Horsts and 
David Guest's as well) that we need a large single textbox to collect all the 
information we type in,  use our own intelligence to aggravate and format 
this within this text box, and use the smarts such as popup phrase wheel to 
provide the time saving mechanisms to save typing complete words/phrases, , 
provide the popup structured data entry edit area's when needed (eg 
vaccination, scripts, past history item etc).

Regards

Richard



On Wed, 14 Sep 2005 04:58 am, you wrote:
> At 2:30 PM +1000 9/13/05, Richard Terry wrote:
> >Karsten et al,
> >
> >...this time including all the soap
> >stuff from one consulation into a single cell as opposed to the last one
> >where one soap line gave a single cell.
>
> Can we look beyond the single-problem encounter (visit) to consider
> how to handle something more complex, for I think that is where lies
> the challenge.
>
> Suppose a patient comes in for an encounter, and they need
> - diabetes medications revised, because sugars are running high
> - diabetic foot care
> - review of hypertension with change or reordering of medication
> - review of lipids with change or reordering of medication
>
> And suppose they have health issues of
> - diabetes mellitus (control)
> - diabetes mellitus (foot care)
> - dyslipidemia
> - hypertension
>
> We could have
> - diabetes mellitus (control)
> S - Having trouble adhering to diet. Checking ~ 2x daily, staggered
> times, 9-13 mmol/L
> O - Last A1C 0.09% ( is it under O we would comment on test results,
> or under A?)
> A - Agrees to incr meds while continuing effort at wt loss
> P - Incr metformin 500->850mg bid
>       (using whatever trigger text would activate the medication list)
>
>   - diabetes mellitus (foot care)
> S - Noted slight drainage on socks past 3 days. No
> pain/red/fever/trauma but new shoes 7d ago.
> O - (Details of exam)
> A - Whatever
> P - Whatever
>
> likewise for dyslipidemia and hypertension
>
> Richard may prefer to enter all this in a *single* SOAP note (maybe
> I'm wrong).  But under what Karsten has been proposing, the "parts"
> (dm control, foot care, lipids & hypertension) would each be
> encountlets  (encounter-lets) within one encounter.
>
> So if the RFE originated from a patient saying "foot problem and
> refill BP meds" is this a single row RFE that gets attached
> unalterably to whichever issue the front desk or the doctor chooses?
> Is there a requirement that each encountlet have an RFE, or can we
> have a single RFE for the encounter?
>
> In our display of what occurred in that encounter, if in the EMR tree
> we clicked, inside an issue/episode, onto a single encounterlet, we
> would presumably see only its parts (together perhaps with a shared
> RFE if it's possible).
>
> RFE
>   S1
>   O1
>   A1
>   P1
>   AOE1
>
> However it is important that we be able to "see' the entirety of what
> occurred in a visit. So we would need a means of being able to select
> an encounter (meaning to include/display all encounterlets from that
> encounter).
>
> And what form of display would be desired? A compact form
> RFE
>   S1 & S2 & S3 & S4
>   O1 & O2 & O3 & O4
>   A1 &A2 &A3 & A4
>   P1 & P2 & P3 & P4
>
> as well as perhaps the option of seeing the parts split-up:
>
> RFE
>   S1
>   O1
>   A1
>   P1
>   AOE1
>
> S2
>   O2
>   A2
>   P2
>   AOE2 etc
>
> Now here comes one extra part to resolve. The AOE. Maybe we are not
> required to have an AOE for each encountlet since we spoke of using
> (displaying) the A in cases where no AOE had been input - or is
> GNUmed in the event of a "null" AOE in fact copying the A into the
> AOE for *each* encountlet?
>
> If not, would the user have an option of using a single AOE to tie
> together the parts into a synthesis e.g. new shoes / cellulitis /
> hyperglycemia / high BP (role of NSAIDs?)
>
> Can the AOE be attached to the encounter without having to be
> attached to a specific health issue? Or assuming it nust be attached
> to *one* health issue, some ability to display AOEs *irrespective* of
> the particular issue to which it was attached?  We already employ the
> "gathering tool" of episodes "unattached to a health issue". But to
> add to the tree an issue line that gathering up all AOEs distorts the
> tree.
>
> What about if instead, in the EMR tree,  we offer a toggle choosing
> whether to display by issue (as currently exists) *OR* switch to a
> tree of encounters as follows:
>
> Encounter date/time
>     AOE xcvxcv nbncxb bxnbcnx
>     expansion triangle
>
> under the expansion we would have the encounterlets that made up the
> encounter, and each encounterlet would be denoted by its issue name &
> assessment info (or AOE if this had been input down to the
> encounterlet level?)