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

[Elizabeth Dodd]

On Fri, 2 Jul 2004 08:39, Richard Terry wrote:
> 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.ht
>m
>
> 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
>
>
>

The first thing I note is the new term for browsing in a reverse direction 
"Pevious"
Now, Ian lives in a dream world in which you enter all the previous history in 
a 'first consultation". Real world doesn't work like that, as the years go 
by, you find out all sorts of things that weren't revealed before - we are in 
a position of trust and as the trust grows, then old items of history get 
revealed, and have to be added to the list. Whether this is done by going to 
"past history" or is done in the edit area for the problem list, I cannot 
say.
On our old paper system it is kept as a separate page, one kept on top of the 
main pile, a summary but not part of the main flow.
Liz

-- 
Slang is language that takes off its coat, spits on its hands, and goes to 
work.