gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] vaccination indication input panel


From: Jim Busser
Subject: Re: [Gnumed-devel] vaccination indication input panel
Date: Thu, 03 Jun 2010 11:15:51 -0700

On 2010-06-03, at 4:15 AM, Karsten Hilbert wrote:

>> Not sure I understand the "... or indications"

ok... *now* I am *closer* to understand :-)

Would the dialog be as follows where, with the existing:

        Vaccine: (this is a field; upon widget invocation, this defaults blank)

        Indications: (checkboxes, upon widget invocation, these default 
non-selected)

and the user can do as follows:

- begin typing a value into the Vaccine field, which will (or can) invoke a 
phrasewheel of existing vaccines. When the user selects a previously-created 
vaccine, the previously-associated checkboxes will be fetched, and the screen 
will be updated to show those checkboxes

- will the checkboxes be always "live", so that -- after fetching an existing 
vaccine -- if a checkbox gets inappropriately unchecked (or newly checked), 
this change of state will be saved with this vaccine definition, and will 
affect all patients against which this vaccine had been registered? Therefore 
upon clicking the OK should GNUmed test for a change in boxes, and query the 
user whether it is truly intended to reclassify every patient as to what they 
had previously been vaccinated against? This seems risky. Should it need gm-dbo 
access?

- alternatively, upon fetching an existing vaccine, prohibit the checkbox 
indications to be altered. Only if the vaccine name would get edited should the 
checkboxes again be allowed to be altered. This stands to confuse the user 
*unless* the GUI will support to auto-dim (read-only) the checkboxes on 
"vaccine load" and auto-enable checkboxes immediately on any vaccine name edit.

- if the *first* action in the dialog is not to input a name fragment into 
Vaccine but -- instead -- to checkmark one indication, it sounds like the user 
will be presented with suitable vaccines among which the fake single-indication 
one. If none of offerings are suitable, an Add button will be available in a 
no-match / multiple match dialog?

- so far, the user selected only one checkbox, so what if it is a combination 
vaccine... if the fist indication would have resulted in matches and landed the 
user inside some second dialog, does the user need to dismiss the dialog in 
order to be able to click additional indications? If they *then* wish to have 
this combo-selection as a new vaccine name, they need an Add button at the 
top-level dialog?

Upon trying to create a new vaccine, GNUmed must presumably not allow name 
duplicates. Therefore:

-- when no indications were pre-checked, entering a name in Vaccine can only be 
a search. Yet if the characters did not yet match a name, would the indications 
remain editable / attachable to this to-be-cretaed vaccine?

-- what if one or more indications *were* pre-checked before inputting a 
vaccine name? Then, if a name is supplied, this would be a "vaccine creation" 
UNLESS the vaccine would name-match something already-existing. This would be a 
conflict, and the user should maybe be alerted and informed that the 
already-exiting vaccine will be displayed. This should reset the checkboxes to 
reflect the indications that had been saved previously.

-- for any one Vaccine, will batch numbers be saved so that, upon a search, the 
user could maybe re-select an already-used (matching) batch, or would the user 
select just the Vaccine name but the last-used batch would auto-populate the 
field which the user could keep or change, or would the batch be left out 
altogether and require to be, each time, entered?

- what happens for unsupported indications? enter instead as a plain soaP line 
(pending a future release of GNUmed)?

- when an exact date of prior vaccination (based on patient report) cannot be 
recalled and entered with certainty, likewise use the Soap approach?

-- Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]