|
| From: | Jim Busser |
| Subject: | Re: [Gnumed-devel] Waiting list improvements needed |
| Date: | Thu, 16 Jul 2009 22:19:12 -0700 |
It is maybe a problem that AFAICT no "first iteration" got defined. I am not even sure what it is (was) supposed to be, lacking as I do any knowledge of anyone having defined something minimal that would actually be used by them in production. The fact that Up / Down buttons were deployed into this "first" (?) iteration qualifies them for feedback. My pointing out that these remain of limited use – unless and until a dependency on an improvement could *at some point* be resolved – does not qualify the feedback or related proposal to be "way overboard" given their intent only for *some* future implementation. Provided you were only hoping / nudging for me to not (personally) have too high expectations – which BTW I did not need, but accept in good temperament – then I do not object to what was meant by the characterization. You and whoever else would code can decide the scopes of iterations. If I can get my head out of the trees and up to the level of the forest, I can see two main modes of using the Waiting List: 1) Current patient mode 2) Waiting list mode 1) Current patient mode Patient phones, let us say it is that annoying Spock, asking whether something he awaits has been done. Kirk happens to be in focus and is standing right beside me on his way out. Suppose I am the office assistant. How am I to answer Spock? I'll think to check the waiting list, which I search for Spock. As a result of "finding" (bringing waiting list focus to) Spock, no items are found. Was the item taken care of, and removed (deleted), or did someone forget to register the task? Silly me.. while the Waiting list's "Zone" field *does* filter, the "Patient:" field does not, it only brings into focus a patient, making it possible for them to be linked into a *new* item if one would be here *added*. However, even if the list *did* filter, I would be unable to answer the question. I have actually wasted my time searching Spock within the waiting list, and must now search him again in the primary search field, hoping the answer is somewhere in the notes. Before I do, can I point out the potential for medical error? We have one patient in primary focus (Kirk) at the same time as we have another in focus (Spock) in the waiting list search result. If I click the Demographics, Kirk's will be shown. Kirk is standing in front of me on his way out from a visit but – despite that he is still in primary focus – if he presents to me a task from the doctor that I must create, I better not click Add, because that will attach the item to Spock. So I actually think the most important fixes to the current iteration are to disambiguate the above: 1) Relabel the "Zone" label to "Filter on Zone:" 2) I would seriously question having a patient focus field within the plugin that allows a different patient than the one in primary focus. I think this should be removed, and replaced by accepting the constraint that you can only create a person-waiting-list item for the person who is in primary focus. The only reason to search inside the plugin is to keep the primary patient in focus but it is no more work to search from within the primary search field (and less work once a system-wide keyboard shortcut would be implemented) and the previous patient is easily enough returned to by exposing the dropdown list. I would have us relocate the Add button down, next to the Remove-to-be-Delist button and, if no patient is yet in focus, there should be a "beep", and the status line should report "Cannot add [Waiting list] item: no patient selected". I am still uncomfortable with the Activate and Activate ± buttons. I am gathering that the rationale underlying the "Activate ±" is that the user does not want to be annoyed by having to come back to the Waiting list in order to remove the item that the user expects will have in the meantime been taken care of. The problem is that the only thing that Activating a patient does is... well... activate the patient. So <facetious mode> I would accept that where the sole purpose of the "Waiting list" item was for someone to activate the patient </facetious mode> then it would be safe to do this. Otherwise in amy medical setting in which I have worked there is an amazing capacity for distractions and for current tasks to get interrupted, let alone the barriers (like patient or target health service) to be unable to be contacted. To me, it would make far more sense to relabel the leftmost button "Activate patient", remove "Activate ±", and replace it with "Filter on patient" To the right of the "Zone" filter, I suggest inserting (before the patient count) a small "X" button which would clear the contents of the "Zone" filter, since this is less work than to have to get focus into the field and have to backspace over it. Sorry for the length of the post, as there is more below (inline). how On 16-Jul-09, at 1:28 PM, Karsten Hilbert wrote:
It still remains that – when rows exist but contain no data in particular columns – columns are displayed in a width so narrow as to show only a character, give or take a half, from the column label (see screenshot). It seemed to me reasonable to wonder about solutions and as to my question about "trimming", I was only getting at the fact that where text values had been stored in the backend without the full storage being utilized (say, 20 of 250 allowed characters) the remainder might be stored padded as blanks. For the widget by default to display the full content of the field (250 characters wide) could affect the default column width. I wondered whether to ask the widget to instead display an operationalized value (display the contents with trailing space removed) could narrow what may otherwise be excess default "width".
While it goes without saying that the backend storage definition (and capability) have got nothing to do *directly* with the list column size. However, if what widget-software *displayed* was closely tied to what was the widget permitted to edited in a widget row, it would be possible that the *widget* might constrain an edited string length to be no longer than the instance's "trimmed" length. While one might consider such a reality "stupid", it is the reality of some applications of which I am aware. Maybe GNUmed superimposes no data constraints in the GUI or middleware and only transparently allows the backend to levy its own enforcements per schema definition?
Maybe waiting list items would chain to plugins. Maybe "activating" a waiting list item of zone "Appointments" would not only activate the patient but activate the plugin. Maybe the comment from the waiting list could default into the newly created appointment. Maybe activating a waiting list item of zone "messages" or "calls" or "cancellations" would activate the patient with the "Demographics" plugin activated.
if the above would be kept, the misinterpretation will be perpetuated.
Well... the roadmap / mini-projects hope to give GNUmed at least one level of undo, and you are hopefully just being facetious, so is it reasonable (as a proxy for undo) to get the user to confirm the delisting: "Really delist the item?" >;- )
Zone could be the person or role who is to look after it, or the kind of thing that is to be done (which may imply the person or role). This is different from whether or not it has been done. If it was requested that an appointment be made, or a message relayed to a medical office, it can useful to know that it was done. Without a status, the office assistants would presumably have to be generating new documentation in the patient Notes which a) I am not sure we want them to be doing (creating "Notes" unless you intend these should include office helpers' non-clinical entries) and b) it may be overkill and a make-work project for the staff While I suppose users would at times see value to editing (updating) the comment -- for example appending or prepending "done" and optionally inserting extra detail -- the item would remain in the waiting list. What should they then do? It would make little sense to have gone to the trouble of recording the detail only to "remove" (delist) the item and make it disappear into the presently inaccessible audit log. The user could re-assign the item to the zone "done", but this would devalue later disambiguation of the items historically handled on a patient, if finding a transaction proved later to be important. Having gotten the above off my chest, I can accept that 'a' solution may be the ability to alter the comment (as above), to remove the item (as is currently possible), *and* to be able to review audited items. But this would still cost the value of being able to know it had been judged to have been "done" as opposed to just "removed / deleted" which (humans being lazy) the comment may not show. You yourself are advocating the functionality of "Activate and remove" which surely is intended at times to treat the item as "dispensed with" even without change to a comment. By no means do I come close to assuming the above would be iteration 1 or even 2 or 3. We only never specced out what a waiting list could *desirably* do and reassign all but the basics to "future". It could be argued that "Up / Down" do not belong in a first iteration :-)
Earlier list answers about where overlapping dialogs could be placed suggested we had limited if any control.
It is just that between phone calls and patients showing up at the desk and further interruptions among office staff and doctors, the contents of short term memory between reading the task, activating the patient, and having the opportunity to complete the task are easily disrupted.
+1 ? |
| [Prev in Thread] | Current Thread | [Next in Thread] |