Re: [Gnumed-devel] Changes to GuiMain - Suggestions (ctd)

[richard terry]

To further re-iterate on the reason for the two column approach to the screen 
design. The reason one needs about 60% of the screen real estate on the left 
hand side, apart from the previously given reasons below, is that it is an 
ideal size to reproduce a 'page' of information to display. Eg one can 
display most of an A4 letter in this area, an Xray image, a drug monograph, a 
graph with decision support attatched, drug interactions etc. These visually 
fit well there. If you go for a three column approach as suggested by david 
it simply doesn't work.

The remainder 40% on the right hand side is also ideally sized so one can fit 
most lists of things, reminders, the scratch pad.


On Tuesday 07 May 2002 8:59 am, you wrote:
> Can I make a suggestion. Obviously everyone is going to have slightly
> different Ideas. Could those who have eg David's comments send me a sketch
> of the relative sizes of the screen you wish to be apportioned to whatever,
> and I will do some mucking around in VB to see how your ideas link to
> functionality and the incorporation of decision support.
>
> I think it is vital that this prototyping be done so as to incorporate any
> new ideas with merit, or to show others how their idea can either already
> exist in the paradigm or be traded off against some other functionality.
>
> a Simple box sketch would suffice, I've time this week and over the weekend
> to muck around with it.
>
> David, I think we have the opportunity here to do more than just 'record
> data items' in a vertical column. The whole idea of the 'word wheel' as
> used in my program is to minimise typing and to provide contextural
> information when needed in an intelligent way.
>
> I would assume that in the distant future consultations will be
> automatically videoed, translated on the fly, the computer will sort out
> what the doctor said, what the patient said, what was presenting symptoms,
> what was doctor assessment, and put them logically into notes. However this
> is a long way off.
>
> In the meantime we can get much more out of progress notes than just list
> them in a column.
>
> Consider that during a consultation I might write the following.
>
> S: URTI symptoms
> 0 :ENT NAD, febrile, cough, chest - left basal crepitations,
> A: left basal pneumonia
> P: Amoxycillin 500 tds, paracetamol etc
>     FBC for wcc
>     CXR
>     review 10/7
> (incidental items might have occurred as well:)
> Scripts given for dichotride for stone
> Reminded faecal occult bloods due 0 given form.
>
> Now, your progress notes already have a fair bit of 'auto-generated' text,
> namely the script data, the request forms for CXR, pathology forms for FBC,
> scripts for the medications including what they were for the doses, repeats
> etc, and info re the reminder. All this was generated just by your
> activity.
>
> As for the SOAP notes, much of that can be auto-generated as well because
> the information is contextual eg the minute you start typting UR, up pops
> the word wheel options around symptomatology (cause the program knows that
> in the editing area you are typing on the symptoms prompt line), so often a
> minimal one key press allows you to select the symptoms. Once you hit the
> enter or tab key and end up on the Objective line, again, contextual
> information is presented in the word wheel using YOUR LANGUAGE, ie the
> computer has learnt from previous consultations how you describe patients
> symptoms with URTI's, so again a short pick list is easy to choose from, or
> you can add new terms if needed. In reality we use the same language over
> and over again. Hitting enter brings us the Assessment line, which operates
> similarly etc. The Plan line can be further refined so that typing Amo
> brings up the word wheel with amoxycillin (which the system recognises as
> an antibiotic hence includes the doses etc, so just the act of selecting
> amoxycillin 500 will autogenerate a script for the caps (as this is an
> adult, or syrup if it were a child at the approprate dose for age), so you
> may not even have to switch to the script module.
>
> At the same time the system is monitoring what you are doing because once
> the symptom line got the URTI symptom the decision support guidlines start
> to swing into action using Ken's information set and underneath the editing
> area start to appear guidlines for managing and treating URTI's etc.
>
> All this is acheivable using current technology and databases. Malcolm
> Ireland and I (malcolm is an academic GP/practicing GP/head of HUDPG IT
> department in NEwcastle/has IT degree from uni) sat and played with this
> stuff back in 1996/7 and even using vb3 it was easy to implement.
>
> Note that you need about 60% of the width of the screen to acheive this.
> the remainder on the right being used for your lists of meds/path etc, the
> scratch pad, and reminders about overdues.
>
> The reason you need this space is as follows:
>
> -_________-----------------------------------------------------------------
>---------------------------
>
> | Subjective   | URTI;cough;runnynose;fever;
> |Objective     | T38;unwell;left basal chest crepitations;increased RR;
> |Assessment | basal pneumonia;left;urti;
> |Plan            |  CXR;FBC;Amoxycillin 500tds;Paracetamol;Review 10/7
>
> ---------------------------------------------------------------------------
>----------------------------------- decisions support txt: current
> recommendations for the management of urti's are.. bla bla bla
>
>                                 :  where secondary infeciton is present
>                                 : first
>
>                           line agents are amoxycillin (covers xyz bacteria 
...
>
>                                  bla bla bla    (click here for more
> detail). (note the font size/colour is different so it doesn't distract
> you)
> ---------------------------------------------------------------------------
>------------------------------------- (and underneath this there is still
> room for a list containing info you need to pay attention to but havn't yet
> eg)
> - there  are 3 outstanding pathology reports for this patient
> - letter from cardiologist Dr All Heart not yet read
> - missing immunisations: fluvax, pneumovax
> ---------------------------------------------------------------------------
>--------------------------------------
>
>
>
> Inputting data in this format is incredibly quick, and if saved in an
> appropriate fashion lets you pull back alot of detail for research. The
> computer can also monitor wether you take the time to access the decision
> support info, the same area under the editing area automatically can pop up
> disease/drug interactions at the same time (eg having noted you put the
> patient on drug X, it may recommend that because the patient is on drug Y
> that it's dosage is reduced, or that because the patient has renal failure,
> a drug dosage is reduced.
>
> Note that  ALL OF THIS IS VISIBLE IMMEDIATELY TO YOU.  Once you confine
> yourself to either small vertical columns, or screen wide text boxes you
> really restrict your screen real estate.
>
> Putting some notes in in this manner can allow you to input a whole lot of
> info automatically eg if the Objective line contains BP=120/70, this is
> automatically parsed and stored as systolic/diastolic if W=79.4 etc the
> weight is automatically stored.
>
> Anyway, Have to see some patients as is nearly 9am.
>
> Hope this helps
>
> PLease send me you ideas re shapes/functionality so I can muck round with
> them.
>
> On Tuesday 07 May 2002 12:50 am, you wrote:
> > On Mon, 2002-05-06 at 22:19, dguest wrote:
> > >   Ian Haywood wrote:
> > > >I would like to propose some changes to the gmGuiMain module:
> > > >
> > > >- move to the 'split-screen' interface like Richard's interface.
> > > >- replace the wxNotebook tabs with a row of small icons.
> > > >- Convert the current windows in the notebook to plugins (find
> > > > patient, cryptowidget, SQL query, Python interpreter, etc.) in a
> > > > "plugins" subdirectory.
> > > >
> > > >Any objections/comments?
> > >
> > > Hi Ian
> > >
> > > I have been thinking about Richard's interface during the week and his
> > > lecture made me focus on what was my main activity during the patient
> > > encounter. For me, as a GP in private consulting rooms, it is clinical
> > > data capture using a keyboard and manipulating the data while accessing
> > > already collected information such as previous consultations,
> > > investigations and other doctors' notes and correspondence.
> > >
> > > I prefer to record my data items one after the other in a left
> > > justified vertical column. This means I need a tall but not very wide
> > > vertical column to record and display the current encounter data. (Say
> > > 40% of the screen width). For access to the other data I need a summary
> > > of all previously recorded items (e.g. investigations, old notes,
> > > correspondence) and a display window for the items that I select from
> > > the summary.
> > >
> > > So, in essence this is a three window screen, with the middle and right
> > > windows being accessed by hot keys and icons as per Richard's
> > > interface. Hopefully there is still room to squeeze in his scratch pad
> > > and Reminders windows. I also liked the way his patients' id window
> > > only took up one line at the top of the screen.
> > >
> > > That's my $A0.02 worth anyway.
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Gnumed-devel mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/gnumed-devel
> >
> > what about 2 monitors for hardcore electronic evangelists?
> > just kidding.
> >
> >
> >
> > _______________________________________________
> > Gnumed-devel mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gnumed-devel