[Gnumed-devel] Re: Carlos - Soap2 - design comments

[Carlos Moro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

| Carlos - I'm not sure if you have read any of the philosophy behind
|
my stuff -
| if not - look at www.gnumed.net/rterry/Index.htm

I have read some time ago.  I really like the approach. Sorry, I
hadn't taken more into account while thinking about the SOAP input
plugin. O:)

| as you can see from the attatched png's I've dumped today, apart
| from the SOAP editor, I've just used some stock wxPython
Demo
| examples to fill in the spaces

I like the design. Find it very intuitive (eg. 251.png SOAP input),
providing/accessing valuable patient's context information. Only i
imagine we need to add a way for targetting  the problem the progress
note belongs to and  the support for multiple SOAPs in the same
time/encounter. Maybe  adding combo of health issues and SOAP widget
like in the image but in tabs, each labeled with the problem name?

I'd like to put hands on coolaboratin and working in these GUI todo
when  final  approach is agreed.

| I keep coming back to the fact that we must have an overall design
| in
mind as
| we do this stuff.

I agree.


Best regards,
Carlos


| On Wed, 10 Nov 2004 05:59 am, Carlos Moro wrote:
|

| Hi all,
|
| Ian Haywood wrote: |> While in fact I do like the approach a lot.
| Carlos has already |> started to use it in writing a SOAP entry
| plugin for HorstSpace. | | Excellent, but please don't pointlessly
| duplicate this work. Speak | up if you want something changed.
|
| The idea is  use SOAP2.py widget as the key input element of the
| SOAP input plugin. I comment the initial approach/proposal, as
| commented with Karsten, including with his feedback  ;) :
|
| ~    -It would be mainly a split  window:
|
| ~    A) On the right: gmEMRBrowser: allows problem selection. Only
| a new SOAP input control can be created when selecting for input a
| new problem. For future:  tree will allow more sophisticate SOAP
| navigation/edition/selection, according patient's EMR. ~    B) On
| the left:
|
| ~ 1. MultiSash seems the adecuate base widget for our SOAP entries.
|  It's completely implemented in python (wxPython/lib/multisash.py),
|  looks really nice and is very effective splitting views.
|
| 2 . When a new split view is created a new instance of the target
| class is created. Perfect for us: create an instance of
| cSOAPControl and pass to it the currently selected health issue in
| the tree (we can improve selection in future).
|
| 3. There would be a unique pair of clear/save buttons in the
| plugin. The user must be really sure wich problem currently
| selected SOAP belongs to. Multisash provides a yellow border in the
| active split, so doesn't seem too difficult. The plugin will query
| the controls for the input and dump to the backend (interacting
| with gmClinicalRecord)
|
| 4. To improve usubility, only horizontal multiusash splitting will
| be allowed, disabling vertical. In that way, SOAP input controls
| will be displayed like in one column from top to bottom.
|
| 5. In order to allow another split SOAP creation (initially by
| dragging the sash creator, we can later improve with the + button),
| we could check that a problem in the tree is selected, and it must
| be different of the problems of the other cSOAP input views. Also,
| we can limit the total views to 3 or 4...
|
| 6. Regarding implementation, we could at first take multisash.py
| and customize to adapt to our needs. In future we can always decide
| to extend or something to make our approach more generic...
|
| I attach a shot of a very first try, yet using old SOAPCtrl...(just
|  for the general idea...) We are synchronized and in contact to
| advance both SOAP2.py and gmSOAPInputPlugin... :)
|
|
| Best regards, Carlos
|
| |> One thing I am wondering about is: How are we intended to deal
| |> with data having been typed into a functional popup ? Eg.
| imagine |> the user incantates the magic string that pops up the |>
| vaccinations control. After completing that control the user |>
| clicks OK. What happens next ? One thing is that we do want to |>
| drop a quick note about the vaccination into the SOAP widget. |>
| OTOH, we would also want to store the vaccination details into |>
| the database. Do we do this immediately when OKing the |>
| vaccinations popup ? If so how do we handle the case when the |>
| user CANCELs the master SOAP control ? If not where do we keep |>
| that information around and until when ? | | Three options: -
| parseable string, when we commit the SOAP, we | parse the text and
| do the database commits. We can mark the text | not-editable to
| prevent the user messing it up. IMHO, with care, we | can make
| strings parseable and readable. - use the string as a key | to a
| cache dictionary of "hidden" objects. This exists in vestigal |
| form already. - wxStyledTextControl markers, which can be |
| invisible, again as keys to a cache dictionary. | |> # - this
| should not be a physical replacement for the edit # |> area, just a
| logical one where people want to use it ! #   IOW we |> will keep
| gmEditArea around as it IS a good design ! | | I hope SOAP2 to be a
| complete superset of cEditArea functionality, | I don't want it to
| co-exist as IM[and Richard's]HO, consistency of | GUI appearance
| and behaviour is important. | | | Ian | | |
| ----------------------------------------------------------------------
|  | | | _______________________________________________ Gnumed-devel
|  | mailing list address@hidden |
| http://lists.gnu.org/mailman/listinfo/gnumed-devel
|

~ -------------------------


~ -------------------------


~ -------------------------


~ -------------------------


~ -------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBkbgG5BCD+/pQ4WIRAj9gAJ9HN4vOWldDW+FezQlcxSl3lDu4gQCgiGdq
iyOWYu4wHcDUdCx6Zc5Kwx4=
=iX0Q
-----END PGP SIGNATURE-----