[Gnumed-devel] Words of Wisdom on Past History Data

[Richard Terry]

Regarding Malcolm Ireland, I must tell you that we have worked extensively 
together over the years designing medical databases and writing (me) 
programs. Malcom with his computing and university background + research 
interests and his lateral thinking was a good counterbalance to my enthusiasm 
and ideas.

After I came up with the editing area concept and wrote the original script 
writing software, we moved on to thinking about medical record progress notes 
input (never implemented). We spent many many hours using the editor concept 
trying various forms of data-input, using the popup lists linked 
intelligently to our underlying coding system (we developed - and I still use 
- our own coding system).  Malcom interestingly, having been involved with so 
much medical software and using another product (Medtech), still is of the 
opinion that my VB client is the best example of medical software around.

Anway - progress notes. I'll flick your request to malcom and ask him to post 
a reply to the list himself. In the meantime I'll make some comments myself

One of the reasons I never moved on to progress notes of the current 
consultation when I wrote my stuff in 1997 was the deluded beleif that 
because I wasn't a programmer, that my effort was certainly a short term 
interim measure - and why waste more of my time, having spent 6 months 
writing my system - when there would soon be something bigger and better soon 
coming along, and I'd drop mine for it.

7 years down the track it never eventuated, however I did have progress notes 
of sorts as shown in the accompanying PNG's. Every activity was recorded and 
became a line of the progress notes, ie scripts, referrals, past history, 
recalls, allergies, vaccinations etc. It was only the history of the current 
presenting  complaint that I never implemented. At the time I generated the 
progress notes from the data_ProgressNotes table as rows, each obviously 
linked to a particular consultation/doctor. I then used Crystal reports to 
generate a nice looking report that could be printed out, or exported in any 
format from XLS to HTML to Word-docs or rich test files. I put in provision 
for a summary of the consultation but as you can see from the screen dumps I 
never implemented it. 

These screen dumps are from a real patient currently attending the surgery 
(with the name suitably rubbed out). As you can see by scanning them, despite 
lack of presenting symptoms and clinically findings,  it is pretty easy to 
follow the flow of what has been happening to him over the last couple of 
years. (This backs up Malcolms observation that the two most imporant things 
are what the patient wants and what the doctor did). There is no reason why 
exactly this sort of format couldn't be used in gnuMed, and displayed in the 
central area of the screen via html formatting. I beleive this 'sequential' - 
a la paper - type of progress notes are the most useful, because we can 
peruse them on the screen, scroll back and forth, and print them out if 
needed, or forward them electronically. 

Additional formats are of course needed e.g to type in a keyword, and bring up 
all consultations containing that, or to choose display by problem and show 
all those.

The main reason I am against the tree type of display is it is slow, unweildy, 
we do not think about consultations in terms of dates or trees (though we of 
course view them in chronological order). Out of all the viewing methods, 
scrolling down the sequential pages is the most useful. In Addition, in most 
of our clinical time we do not even refer to what has gone before, except by 
memory. I guess in hospitals it is different when patients are being seen by 
a number of different doctors.

Just a few thoughts.

Regards

Richard

On Fri, 12 Nov 2004 02:07 am, Ian Haywood wrote:
> On Thu, Nov 11, 2004 at 07:36:03PM +1100, Richard Terry wrote:
> > I spent today using the SOAP2.py editor to enter all my consultations,
> > some 30 of them, telling the patients I was testing 'someones' concept of
> > data entry.
> >
> > Consulations were many and varied, ranging from simple I want a script
> > for
>
> wow, real live testing. And only 24 hours since it was dumping core like
> mad ;-)
>
> > panamax 'Anything else', no doc, just that, to severe agitated
> > depression,
>
> A word of explanation: the patient is a health-care card holder (i.e
> welfare recipient) so they want paracetamol prescribed to obtain the
> pharmaceutical subsidy, otherwise they pay full-price.
>
> > It soon became apparent to me that the SOAP concept just will not work at
> > all and I will expand on that in a minute. I don;t mean  the concept of
> > the SOAP style editor which Ian is kindly writing for us - it is
> > brilliant (of course my concept!!!!), and getting  better every day, but
> > the concept of SOAP itself for separating threads in data entry, I will
> > justify this statement below. I can remember the debates about this on
> > the list, but must admit I didn't involve myself a great deal in this.
> >
> > I ended up late in the day ringing up Malcolm Ireland. Some of you will
>
> <snip>
>
> > I'm sure I could persuade him to reply and expand.
>
> Can he offer any words of wisdom on the presentation of past history
> data, particularly how a summary page should be structured, and
> organising notes, given many (myself including) aren't sure tree widgets
> are ideal, but can't think of anything better.
>
> > Patient Request
> > History Taken
> > Clinical Findings
> > Assessment
> > Plan
>
> This is also generally how I structure admission notes, with the
> addition of "medications" and "past history".
>
> I note the main difference is "S" is split into "Patient Request" and
> "History Taken" [which implies a fifth clin_root_item type, say 'h' for
> history taken]
>
> > History Taken
> > Clinical Findings
> > Assessment
> > Plan: Script Panamax
>
> AFAIK we have always allowed for blank fields, in my current widget the
> SOAP cycle is named after Assessment, if blank Subjective, then PLan,
> then Objective.
>
> > user  should be able to (cannot here in this simple example) link
> > multiple problems to the same consultation notes. If these are stored
> > correctly, it should be a simple manner of pulling out all consultations
> > which were linked to a particular problem and formatting them with html
> > when you need to review a particular problem.
>
> Currently the backend schema allows each clinical record fragment
> (correspondes to each semicolon-delimited phrase in the SOAP widget)to be
> linked to *one* episode. (but a consultation record contains muliple
> fragments) I agree having seperate SOAP widgets for each problem is
> clumsy, but to move to this model (where the whole consult is linked to
> one or many problems) requires a big change in schema.
>
> Also, fragments (that is a single clinical sign, diagnosis, element
> of history, plan action) *do* relate to a single problem, it would be
> nice to be able to see only those parts of the narrative relating to a
> problem (of course you can expand the view to give the whole consult
> notes where a problem is involved).
> Currently we have a drop-down list in the top right-hand corner that
> lists the current active problems, whatever you do in the rest of gnumed
> is recorded under that currently selected problem, the SOAP editor would
> need to query this control at the completion of each semicolon-delimited
> fragment (which is easy) to figure out what problem to record that
> fragment under.
>
> Of course we can reserve some function keys (say F2/F3) so the user can
> quickly move between problems while typing.
>
> Ian

progress_notes_1.png
Description: PNG image

progress_notes_2.png
Description: PNG image

progress_notes_3.png
Description: PNG image