gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Richard Terry
Subject: Re: [Gnumed-devel] emrjounalplugin.py comments further html work
Date: Mon, 19 Sep 2005 08:07:46 +1000
User-agent: KMail/1.8.2

I take in all you say. You must be fairly unique amongst doctors Karsten, or 
or perhaps it is the german system, or the sort of clinic you work in.

Reason: I've perused many many thousands of clinical records from patients 
from many hundreds of doctors in my time, and it exceptionally rare to find 
structured notes. 

In my 'on-the-ground' tutoring of GP's in the use of clinical record programs, 
and in projects where we wrote the software specifically to enforce entering 
a reason for encounter (for research projects), we had a huge problem trying 
to educate doctors how to use that, and also if they knew how, getting them 
to fill it in.

In my own consultations I reckon there may be about 50% of consulations I 
could tag with something sensible.

Must be different in Germany?

Regards

Richard

On Sun, 18 Sep 2005 11:00 pm, Karsten Hilbert wrote:
> On Wed, Sep 14, 2005 at 08:19:45AM +1000, Richard wrote:
> > Regarding your comments on complexity I agree we have to
> > look beyond the single encounter visit.
>
> Beyond the single *problem* visit, right ?
>
> > As you mentioned, having to input SOAP notes as we do
> > currently, we end up with
> >
> >  S ...
> >  O ...
> >  A ...
> >  P ...
> >
> >  S ...
> >  O ...
> >  A ...
> >  P ...
>
> That is what I would expect. It also fits my workflow quite
> well. I capture what I am told, what I find, what I think
> about it, what I do about it. I am going back and forth, of
> course, but in general that's how I work.
>
> Notice how this does not predefine how the data is
> *displayed* later on !  The EMR is a tool to make things
> *easier* for us. We can use one format to make input follow
> our workflow but use *another* format to guide our reception
> of information later on. The requirement for this ability is
> that the input is in some sort of structure. That's
> precisely the point. On paper I am forced to write down the
> notes in a way that will facilitate easy reception. No
> reformatting is possible unless I have the notes
> transcribed! Such *is* the power of using a machine and
> using structured data. That's exactly why we want to give
> the machine some idea of what's what !
>
> So, in the end, the statement "we end up with ..." is wrong
> (thanks $DEITY). What we end up with is a bunch of unordered
> lines of text thrown into an opaque bag called "table". It
> is *our* responsibility to grab the proper lines from this
> bag and display them any way we see fit. For that to be
> possible we need to add metadata to the text when throwing
> it into the bag: who, when, what type of text, which
> encounter, which problem, etc.
>
> > The essence of the encounter which we as a doctor
> > immediately grasp is that of poor diabetic control
>
> Hence we use "poor control" for the AOE of the encounter and
> "foot problems" and "high sugars" for the progress note
> assessment lines.
>
> > 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'
>
> And yes, one could reformat the above notes into that sort
> of display - that's precisely what I asked for when I wanted
> HTML snippets for how you guys want the notes to be
> formatted. The above is simply:
>
> $health_issue
> =============
>   - soAp
>     Soap
>       sOap
>       soaP
>
>   - soAp
>     Soap
>       sOap
>       soaP
>
> (Apart from the fact that we cannot currently have two open
> episodes at once.)
>
> > 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,
>
> Sure, no problem. If you guys want a single text box you can
> have it. Simply save all the text under, say, Soap (or
> whatever category) and be done with it. Within that
> narrative line the information can be structured any way. A
> viewer can be made intelligent enough to not destroy the
> pre-existing formatting and to ignore empty categories. That
> way within the structure unstructured data is saved. The
> additional structured data (scripts, vaccs, etc) can happily
> coexist.
>
> Karsten




reply via email to

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