[Gnumed-devel] SOAP - Edit Area - Parser - some thoughts

[Richard Terry]

Having slept on the issues surrounding this I'd like to make a few 
comments, from the functional and visual point of view.

Before reading this, click on this link from old documentation to 
visually refresh your memory (this is a script screen dump).

http://www.gnumed.net/rterry/full%20screen%20-%20comments%20on%20design3.htm

Now imagine this section is actually for progress/SOAP notes, and 
mentally in your mind substitutes the follow:

The 'Prescribe for' drop down list becomes the existing problem list (ie 
already in medical records) which the user could select from to 'tag' 
the contents of the SOAP editing area.

The editing area labels are obviously Subjective Objective Assessment 
Plan etc (whatever else needed).

Once the information is entered (and perhaps with a 'smarter' editing 
area which auto-expands the row sizes as more space is needed), then 
like in other sections the user clicks the OK button and those SOAP 
notes become a discrete entity dropped down on the list below the 
editing area as a line entry, for example if the past problem was 
Hypertension then the list would contain (as a single line)
--------------------------------
Hypertension:S:.......O:.......A...... P...... etc with enough detail 
showing to allow quick contextural recognition.
---------------------------------
If the next SOAP entry for the consultation was entered, it is initially 
labelled as 'undifferentiated' or some such word in the text box where 
the existing problems can be selected.  As the user enteres the notes, 
the problem may become defined eg simply URTI, so that when finished the 
list below the editing area now becomes:
---------------------------------
Hypertension:S:request BP check..O:.130/80......A..good control.... 
P...script... etc with enough detail showing to allow quick contextural 
recognition.
URTI: S.cough,runny nose.....O.NAD..A:Viral URTI...P:  Symptomatic etc
--------------------------------
The Next problem  is entered and may be undifferentiated, so the list 
becomes:
---------------------------------------
Hypertension:S:request BP check..O:.130/80......A..good control.... 
P...script... etc with enough detail showing to allow quick contextural 
recognition.
URTI: S.cough,runny nose.....O.NAD..A:Viral URTI...P:  Symptomatic etc
Undiagnosed: S vaguely unwell.....0:nil to find A ?diagnosis P.FBC, ESR, 
etc..

Where the Undiagnosed is internally tagged so the SOAP notes to allow 
recall.

At any time during the consultation, the user can click on any of these 
3 list entries (Just as they can in requests/scripts/recalls etc) and 
re-edit the text to add/modify that problems notes. Once committed of 
course and not part of the current consultation these notes can be 
reviewed but not modified.

By using the usual pop up right mouse menu's the user has the 
flexibility to view say 'all  entries for hypertension', which when 
selected, overlays the central area (as we do when displaying PI, or a 
letter), with a chronological listing of all consultation entries for 
the clinical entity, here hypertension.

Previous comments about parsing
========================

Personally I don't beleive that is silly as it sounds, except I'd hasten 
to agree with Karsten that at this stage of evolution we should 
definately not try and parse natural language. However, parsing has a 
place. I do it extensively in my program on a very simple level - e.g to 
spell check all the words, to remove additional blanks, to separate test 
names etc which are separated on thes screen by my delimiter (eg 
FBC;ESR;UEC;LFT;)

Now, getting back to my comments from a previous posting about having 
purpose build 'edit area' editor, which auto-expands the available lines 
as one runs out of space, this is a situation where simply parsing comes 
into its own. It is then used to parse out and link the lines opposite 
the labels which are embedded in the edit area, but can also be used to 
parse out say a tag the user has insert using control keys eg hitting 
Ctrl(whatever) to insert the visual (different coloured tag) BP=. The 
parser assumes what comes after this tag must be in the format nnn/nnn. 
It both in real time validates the input is a digit (I do this very 
simply in the measurement part of my program), and later, when the user 
clicks the OK button to save  the data, assigns any BP measurements to 
the appropriate measurment fields. Hence later one could simply review 
all the BP's in the medical records with dates.

I think kept simply this would not be that difficult for a programmer to 
implement. As I mentioned many years ago I did something similar if 
FORTH. I think the mistake is to try and make it complex.

I would be happy to work with sjtan who seemed enthusiastic about this, 
to explore if we could use an existing wxPython control/python code to 
do this, and see if we can come up with a 'proof of concept editor'. 
Obviously this is only possible if someone like sjtan does the coding, 
as I'm not capable of it, however I can certainly guide the clinical 
functionality. This may be a 'dead end' approach, however I think it is 
a very powerful concept and could catapult gnuMed into the forefront of 
medical record data entry, building on the existing editing area concept.

Thoughts?

Regards

Richard