Re: [Gnumed-devel] allergy manager in CVS HEAD

[James Busser]

On 15-Oct-08, at 2:54 AM, Karsten Hilbert wrote:

> Attached find a current screenshot of the allergy manager.

Looking good... even so...

1. if it is desired to alter the allergy state, it is extra work to  
both change the value of the "Set to" radio button, and to also have  
to click "Save state". It would be more efficient to simply auto-save  
any change made to the state, unless there is a desire to refresh the  
screen immediately. I would suggest:

(a) improve the flow by switching positions of the allergy state  
comment, and the allergy state "Set to" radio buttons. The comment  
then follows as a qualifier on whatever state was clicked.

(b) in place of separate "Reconfirm" and "Save state" buttons, what  
about a single button "(Re)confirm" which would support either  
context by updating the clinical ascertainment (even if there was no  
change) that the information now-shown is current to the best of our  
knowledge

2. please confirm the flow as it now stands in "head":

- on patient creation:
        default allergy state would be "unknown" ?
                for if it is null, what would show in the radio button?
        default state confirmation timestamp would be null?
                'Last confirmed" would show in the manager as <null>?
        cave would show "?"

- after asking the patient:
        if unsure or evasive, clinician enters a comment
        if radio button is left as "unknown"
        --> cave shows "?!"
        if radio button is set to "none" yet a comment exists
        --> cave shows "greek phi with !"
        if *has* allergies
        --> there is still a role for a comment (?)

- after the "Last confirmed" has been altered from null, shall we  
indicate this as part of the Cave for example
        ?! (last confirmed yyy-mm-dd hh:hh)
        phi (last confirmed yyy-mm-dd hh:hh)

... since it would spare the user having to expose the tooltip to  
decide if it was recent enough (it is a tradeoff... clutter vs fewer  
steps, I prefer fewer steps and maybe we could leave out the text  
"last confirmed" since the user would figure out the meaning of the  
date the first time they open the Allergy manager

Two more questions:

- if any change was made to the allergy manager info for a patient,  
can that auto-update the "Last confirmed..." even if the user did not  
click "(Re)confirm"?

- I did not see a response to my concern about Generic/Specific  
quoted below... the reply underneath it had been "fixed" but no  
change is clear in the screenshot so maybe was not yet included in  
the scope of change:

> current Generic/specific is dangerous because the default suggests  
> other drugs in this class can be used, when this may not be known.  
> Suggest relabel to "tolerates others in class" and change its  
> default this to "false" until we know the person can tolerate  
> others in this drug [class] or other allergen class (as with some  
> "nut" and berry allergies where is it better to know than to guess  
> tolerability). The existing values for the field do not need to be  
> changed because the semantic remains the same i.e. if their allergy  
> was specific, they remain able to tolerate others in the class