[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] allergy manager in CVS HEAD
From: |
James Busser |
Subject: |
Re: [Gnumed-devel] allergy manager in CVS HEAD |
Date: |
Thu, 16 Oct 2008 14:43:09 -0700 |
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