Re: [Gnumed-devel] Data entry-soap stuff - I tried it all day

[Karsten Hilbert]

> a) "move/jump" the cursor to a different screen area to achieve the 
> same effect as on paper i.e. to put the data somewhere outside the 
> "narrative" portion of the backend - in order to do this, such 
> "areas" would ideally be in view and quickly accessible but would 
> even so be prone to jerkiness as the patient shifts to yet some other 
> content, I would fear for the quality of whatever rapport had been 
> established
Most of our data entry needs will be served from *within* the
SOAP entry area. Moving inside this area (eg from subjective
to objective) does not require mousing and is thus
indistinguishable for the patient from other typing. By
restricting ourselves to SOAP (or it's Richard-named
equivalents) we already only have a minimum physical
distinction.

If the patient tells me

 "Oh, I had the gallbladder removed because of stones back in
  the 80's and ever since that wound on the tummy ulcerates
  from time to time."

I'd hit <CursorUp> until reaching the "History taken" section,

then type "hx" which would trigger popping up the past history
"edit area" allowing me to keep typing

 "rec post-CE (lith) dehiscence (?systemic cause)"
 <TAB>
 "80's"
 <TAB>
 <SPACE>

whereby I had filled the fields "condition", "when", and
"significant". Hitting <Enter> would store condition and
significant as a health issue (likely significant would be
true here) and store "$condition since $when" into the History
Taken narrative.

Similar for vaccinations (Plan field), allergies (subj/obj),
scripts, referrals, etc. The popup would add a dict to the
SOAP widget data store which will later be stored in the
appropriate special table and also enter a suitable short
narrative note into the part of the SOAP widget it was called
from.

As long as the SOAP entry hasn't been finalized (eg. saved) it
might be possible to keep the popup content editable by
re-popping the relevant edit area somehow.

Actually, technically, it occurs to me that we won't even
strictly need a way to associate parts of the narrative with
the "holding dicts" from the popups...

> b) *not* moving the cursor, instead:
>    i) enter a mode in which the input text/string continues in place, 
> but is visually indicated as being tagged to be either moved or, 
> better (?), copied into the pertinent "other section" or
Which is much like what I suggested above.

>   ii) the input text/string continues in place, but is able at any 
> time to have a portion selected and "tagged" as pertinent to another 
> standard "section".
This is how I would propose to handle *coding* part of the
narrative. Select some part of it, invoke code browser to
attach codes, store selected codes in a holding dict, mark
coded string in the narrative, eg.:

Assessment: DMII<ALT-C>

- selecting ICD10 for DMII in code browser
- code keeps dict
    {'DMII:dx:NIDDM':(
            {'system':'icd10-gm-2004','code':'E11.-'},
            {'system':'snomed-ct-us-2002', ...},
            ...
        )
    }
- code inserts into narrative:

Assessment: <DMII:dx:NIDDM>;

Later, when the SOAP widget is saved the parser looks for
<.*dx:.*> in the assessment string, keeps the first part in
the narrative, gets the data from the holding dict via the key
"DMII:dx:NIDDM" and generates a true diagnosis entry in the
backend from that.

> In terms of data input it would seem least disruptive to allow *all* 
> of what a patient says to go into Richard's "History taken" area.
This is bound to happen anyways. It's not about disallowing
the doctor to do certain things but rather about enabling her
to do more if wanted.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346