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

[Ian Haywood]

On Fri, 02 Jul 2004 08:39:08 +1000
Richard Terry <address@hidden> wrote:

> Having slept on the issues surrounding this I'd like to make a few 
> comments, from the functional and visual point of view.
I first started reading this thread on ED night shift, couldn't make head
or tail of it. 

My understanding now is the soAp assessment becomes a running title for 
the episode, it is a text string that may or may not be linked to a coded 
diagnosis.
Sounds good. But (unless I'm missing something) where do health_issue and past 
history fit in?

IMHO "past history" is just a query on all formal diagnoses assigned to the 
patient.
They may be tagged with various levels of activity/dormancy/privacy/etc.
[as an aside, it may be useful to assign some coded daignoses with a default 
high privacy setting, such as STDs and pregnancy termination]
Obviously we still need a separate screen for entering past history on the 
inital consultation
(i.e. 'orphaned' coded diagnoses that don't link to an AOE, and so are by 
definition dormant)
 
With health issues/episodes/AOEs I'm worried users may get bogged down trying 
to decide 
what should be what. Karsten's thread intimates that this can be automatised, 
my understanding is this:
the user is presented with a list of active problems (i.e. active health issues)
if the user tries to attach a SOAP entry to a problem after a certain timeout 
(say, one month, but if we
want to get seriously clever this can be tweaked according to linked 
coded_diagnosis) a new episode is implicitly
created under the health issue. Health issues are named after the 
coded_diagnosis (if assigned), otherwise the 
title of their penultimate episode.

Obviously we should provide an override in the history browser where users can 
forcibly fuse consecutive episodes, or divide a 
longer episode, much as gnumed already does for separating encounters. 

> Now, getting back to my comments from a previous posting about having 
> purpose build 'edit area' editor, which auto-expands the available lines 
[snip]
> 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'. 

wxStyledTextCtrl may fit the bill here.
It's not like the "styled text control" on Windows (which is essentially 
embedding basic word processing functionality) Instead it's designed for 
editing programming languages. So we can define a "language" with
keywords "subjective" "objective" "assessment" "plan" etc, which are coloured.
For each of these we can define local keywords: "BP", "prescribe", etc.
I agree with Richard: this is not full NLP, we are defining a simple 
"opportunistic"
grammar, unknown text is accepted without error and entered into medical record 
as free text.
Auto-completion facilities are provided, this can be linked to anything, not 
just keywords,
so after "prescribe" we can offer a list of drugs, for example.

Not sure about making keywords "out-of-bounds", although this may be possible 
by trapping 
the POSCHANGED event, then programmatically shifting the cursor forward before 
the user notices. 

The problem with this widget is that its the "command-line of medicine" : if 
you don't know the keywords,
you're stuffed.  We could ameliorate this by binding TAB or * to "show all 
keywords in this context" (I would say
? but this particular punctuation has heavy use in my clinical practice) and 
Control-H
to jump to that context's section of a carefully written chapter in the User's 
Manual.

Ian


-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgp_Q8R5auVf_.pgp
Description: PGP signature