Re: Client menu suggestions was Re: [Gnumed-devel] Release 0.5.rc2

[Jim Busser]

On 28-Jun-09, at 2:40 PM, Karsten Hilbert wrote:

Does the client logic, before building the menus, check the specified  

workplace for the presence or absence of plugins as part of deciding  

whether to provide or omit the plugin(s) from the menu system?

No. The plugins send a message to the menu system which

triggers inclusion of a menu item for them.

and can we pull

Show as > tree view

Show as > chronological view

out of the submenu to fit them into the main level of the EMR menu

If we do that we can only add them at the end because those

two items are added dynamically when (and if) the

corresponding plugins are loaded.

Yes... I see that now... as an experiment, I disabled (de-selected) the EMR tree and EMR journal plugins and notice that my EMR menu now has an EMR menu that offers "Show as … >" with nothing in the submenu.

I think that the GNUmed menu "Plugins…" (now "Go to plugins...") offers an easy way to jump to plugins, especially if keyboard shortcuts would be enabled for each.

I now understand that plugins -- loaded from the active Workplace -- can and do show up in multiple menus:

- each in GNUmed > Plugins… (in the order of their appearance in the toolbar), and

- each also gets added to the bottom of one of the other menus or submenus (also in the order of their appearance in the toolbar) and optionally carrying an alternate name

I note under the Tools menu the item "Show archived documents" but since this archive (which is the Documents plugin) seems specific to the person's EMR, it should be relocated under the EMR menu, yes?

Likewise, under Person, we have an item "Attach documents" but since such documents are presumably health-related and not staff employment related, then this plugin also is better listed under the EMR, IMO.

The above-two suggested relocations are offered below in a reworking of my earlier EMR menu suggestions, with clearer rationale:

- Export seems a function all by itself, which I suggested be bottom-most among the fixed items (i.e. above any added plugins)

- below this, dynamically-added items (i.e. some plugins) might (most tidily) come below a separator

- the names that I suggested for some EMR menus -- when the items represented plugins -- did not, and do not, depend that the menus (plugins) be there... no harm is done when they would not be there

- although I take "History taking" and "Observations" to be patterned after the traditional sequence of data gathering, they create or enforce sometimes artificial distinctions, as history and observations are both in reality also (alternatively) inputted via SOAP notes.

Add / edit data - Alt A

Allergies - Alt A

Hospital stays - Alt H

Observation - Alt O

Occupation

Past history health issue - Alt P

---- menu separator ----

Documents - Alt D ("Attach documents" plugin)

Medications - Alt M ("Substances" plugin)

--> presently inactive, as cannot yet add/edit

Notelets - Alt N (New "Notes" editor plugin)

Start new encounter - Alt N

View encounters - Alt E

---- menu separator ----

Search EMR text - Alt S

---- menu separator ----

Export as…

---- menu separator ----

View archived documents - Alt D

View journal - Alt J

View measurements - Alt M

View substances - Alt S

View tree - Alt T