[Gnumed-devel] re : experimental editor

[sjtan]

> Before the Ok button is clicked:
> > > ______________________________
> > > |  Subjective   : earache                     |
> > > |  Objective    : red drum                   |
> > > |   Assessment: middle ear infection    |
> > > |   Plan           : script amoxil              |
> > > ______________________________
> > >                            [btn_ok] [btn_cancel]
> > >
> > > ===============================
> > >     There are  0 SOAP elements this consultation
> > > =========================================
> > > wxList is empty
> > >
> > >
> > > ================================
> > > After the Ok button is clicked:
> > > ______________________________
> > > |  Subjective   :                               |
> > > |  Objective    :                               |
> > > |   Assessment:                               |
> > > |   Plan           :                              |
> > > ______________________________
> > >                            [btn_ok] [btn_cancel]
> > >
> > > ===============================
> > >     There are  1 SOAP elements this consultation"
> > > =======================================
> > > wxList now contains
> > > Middle Ear Infection - (earache, red drum, Plan:script amoxil)
> > >
> > > ================================
> > >
> > > Now one additional functionality.
> > >
> > > If the user clicks on this item the list, you replace the strings in 
> > > the array(0-3) back into the corresponding lines of the editing area.
> > >
> > > This should be fairly simple to anyone who can program. If you get to 
> > > that point you have the whole thing beat. At no point try and save 
> > > the data or link to the database.
>  
This was done about 12 months ago,  I think for allergies, scripts and 
past history,
but things have moved on  , and  K has decided to obsolete the code 
that was done , AFAIK.
I can understand his point of view, since it doesn't neatly fit in the  
clin_root_item is a child
of both clin_encounter,  and clin_episode, and clin_episode is a child 
of a health_issue, with
clin_encounter being a time attributed  top level entity, and 
health_issue a conceptual/categorical
organising concept. There is also currently a SOAP attribute that cuts 
across all clin_root_items,
even those of clin_history, clin_physical and clin_working_diagnosis ( 
which I would have expected are only
part of S, O, and A respectively, and I suppose this leaves vaccination  
, which is almost always P, and
clin_note and clin_aux_note, which are the only 2 subclasses of 
clin_root_item that would seem to need
the SOAP attribute mandatorily).  Where in the current schema do actions 
such as ordering investigations,
and prescribing go ?
I think this should be discussed on the list and whatever K decides, 
gets done, in order
for the clinical part to progress to even 0.1

Here's the summary of the clin structure:

a. Containment structures:

clin_encounter ( time, place, provider):
      clin_root_item

clin_health_issue
      clin_episode
            clin_root_item
          
b. Inheritance structures:

clin_root_item  
   clin_history ( attributed with  past, med, allergies, family, 
social, vaccination  ; and with source - patient, correspondence; 
perhaps this is for 2nd hand info? )
   clin_working_diagnosis ( attributed as per Richard's domain useful 
features, such as significant, active )
    clin_note
    clin_aux_note
    clin_physical
    lab_request
   
c. association structures

identity
   clin_health_issue
   clin_encounter
    test_result


Artefacts produced from clin_root_items that are 'objective' - 
clin_physical , lab_request -
can be stored in  test_result  -  N.B. even quantitative physical 
findings, are a form of test_result, e.g. BP measurement, thermometer 
reading.


This structure seems good enough to hold everything except the script 
prescription, and procedures.

With clin_episode, the main reason I can see for it's existence is that 
it makes it easy to shift a whole lot of
different clin_root_items attached to it from one health issue to 
another, so it provides the ability to deal
with a problem when the actual health_issue is not defined yet, but will 
be over time.

Look , it might be nice to have some drone programmers to do the grunt 
work,  but this is GNU, so
I think everyone is entitled to know what the issues are, and why it 
seems someone isn't ready to say how high
when another person says jump.








> > > The next clever thing to do is the following:
> > >
> > > Starting with this:
> > > _______________________________
> > > |  Subjective   : earache                     |
> > > |  Objective    : red drum                   |
> > > |   Assessment: middle ear infection    |
> > > |   Plan           : script amoxil              |
> > > ______________________________
> > >
> > > Make this happen when the text reaches the end of the line:
> > > _______________________________
> > > |  Subjective   : earache, fever, cough, |
> > > |                      vomiting, rash            |
> > > |  Objective    : red drum                   |
> > > |   Assessment: middle ear infection    |
> > > |   Plan           : script amoxil              |
> > > ______________________________
> > >
> > > Ie you will have to 'shift down' the prompts and insert a blank line 
> > > in the editor as the users text gets to the end of the line. 
> > > (similarly you will have to delete a blank line if one is made blank 
> > > by deleting text). There are scads of ways to do this. When I did my 
> > > text mode text and graphics editor I just kept a map of where this 
> > > were, and inserted blank lines into the control via code as needed, I 
> > > don't know how wxPython handles this.
>  
>
> > >