Re: [Gnumed-devel] Waiting list improvements needed

[Karsten Hilbert]

On Thu, Jul 16, 2009 at 10:19:12PM -0700, Jim Busser wrote:

> It is maybe a problem that AFAICT no "first iteration" got defined.

That's of course true. It only got defined de facto by being
part of released version.

> 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.

My initial intent was to provide the tool that any PMS I
know has: A list holding patients that are currently in the
practice to see a clinician. Along the way - and drawing
from first hand use case experience - I noticed that with a
few minor generalizations (arbitrary zoning, arbitrarily
settable list position etc) this sort of thing can be used
for a lot more than just currently waiting patients. So I
threw in a few bits which made me think "OK, yes, I would be
able to use the current state as a replacement for the
waiting lists I work with daily". This state of affairs, of
course, affords ample improvement.

> The fact that Up / Down buttons were deployed into this "first" (?)  
> iteration qualifies them for feedback.

Absolutely. The way up/down behaves is probably the most
unfortunate of the whole thing :-)   Still, while (very,
perhaps) annoying not wholly unusable (by a determined
person).

> 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.

Jim, your feedback is both excellent in quality and much
appreciated. You've been finding scores of outright bugs and
usability glitches. They come in three categories:

1) bug - something that's truly broken

        Most of those will need to get fixed before we can
        consider 0.5 shippable.

        Some are obscure, rare, benign, or "just don't do that"
        such that they *can* be somewhat deferred.

2) other issue

a) Some I look at and go "oh, yeah" and they are fixed in a   
couple of minutes at most, like renaming buttons, labels,
etc.

b) Others are more like "this is desirable but will take
considerable effort to complete".


Now, currently, my goal is to get 0.5 out the door !  :-)  
So I kept fixing bugs. I got lured into fixing a host of 2a)
issues.

Then I wasn't sure how to handle 2b), particularly when they
were (significant but still only) improvements over existing
and working (albeit perhaps in a queer way) functionality.

*Not* replying to such things seemed an invitation to not
post them so I didn't want to do that. So I got a little
bogged down ...

Re the waiting list: this is entirely a non-issue for 0.5
which I would gladly ignore until after release. Which
doesn't mean there's no room for considering how to make it
better.

Now, on to some comments:

> 1) Current patient mode

That was my primary intention.

> 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?

You switch to your second (or 3rd or 4th or 5th) instance of
GNUmed running on your machine, search for Spock and look up
what data you need.

> 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?

Since the waiting list isn't intended as a tool for
clinical-plan-handling-only it can only be by social
contract at your site that the waiting list zone
"clinical-todo" is used for such things and that whoever
completes items never removes entries (rather comments on
them as completed) until the repsonsible clinician has seen
them (and then removes them). Another policy could be that
whoever completes and removes an item has to document as
much in the EMR of that patient where you could look it up.

Should later any dispute arise over the following of any
local policy then the audit tables can reveal further
information. We don't support that in the frontend yet.

> 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.

How often will you be wasting your time this way ? Once,
maybe twice. You will then know the local policy of handling
things. If that isn't followed GNUmed cannot do much about
non-compliance ...

However, from this use case it follows that searching for a
string within the waiting list columns seems desirable.

> 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.

One of the basic concepts of the GNUmed client is "There is
always one and only one active patient". Most everything
(except where obviously otherwise and clearly noted) happens
on behalf of that patient. That is why it is shown in large
letters at the top. If I want to work with two patient at
the same time I should use two GNUmed instance at the same
time. That's a basic paradigm here and users need to
understand that. It is much like "I must put benzin into
this car, not diesel".

> 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:"

Done.

> 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 can live with that reasoning. Done.

> 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".

Done.

> 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.

That seems entirely OK to me - after all, that's the most
basic reason for a waiting list to exist I can imagine ?

Frontdesk staff is putting patients *onto* the waiting list
and in the exam room I am selecting patients to see now
*from* the waiting list ...

I usually use "Activate" until fully satisfied the patient
has left the practice and is truly gone for today - only
then do I go back and use "Activate+" followed by a last
screening of their record.

> To me, it would make far more sense to relabel the leftmost button  
> "Activate patient", remove "Activate ±", and replace it with "Filter on 
> patient"

We want the filter up top, next to "Zone".

> 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.

True. That's a todo, together with the patient filter.

> 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).

That's right. Nothing much we can do about that without
extensive coding.

> 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.

No, we never do that. All our text fields in the backend are
virtually unlimited in size and do NOT get padded with
anything (user visible) which doesn't belong there.

> For the widget by default to display the full 
> content of the field (250 characters wide) could affect the default 
> column width.

It would, yes, if there are that many characters in the field.

> I wondered whether to ask the widget to instead display an 
> operationalized value

We do that in some places: where we routinely expect
linebreaks and/or longish lines we translate breaks to "//"
and only display the first n characters or so.

> 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.

Ah, I see what you are getting at. No, we don't impose such
limits. Nonetheless, widgets can disafford large strings --
if the text input field is small it is really inconvenient
to enter long strings, that much is true.

Whenever I encounter such a situation I usually use a
notepad-like application alongside the other one and
copy-paste from the notepad into the app.

> 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?

About like that, yes.

>>> - among the buttons, we do not have a consistency in what they relate
>>> to... I would have thought that (unless clearly labeled otherwise)  
>>> the
>>> buttons would pertain to the Waiting list items however:
>>>
>>> - - the Activate and Activate ± buttons do not activate the waiting 
>>> list
>>> items, they activate the patient
>>
>> That seems entirely obvious to me. What would it *mean* to
>> "activate a waiting list item" ?
>
> 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.

OK, I didn't think of this sort of enhanced functionality.
Seems worth keeping around as an idea. Note, however, that
all of your suggestions activate a *patient*, not a waiting
list item ;-)    If anything I'd personally have expected
the Activate+ button to activate PLUS any of the above ...

>>> - - the Activate ± does not "plus minus",
>>
>> It is "Activate+", not "+/-". The - only comes about because
>> the + is the active letter for the button.
>
> if the above would be kept, the misinterpretation will be perpetuated.

Shall we rename it "Actimove" ?  :-))  (Revate ?)  Just kidding.

I do agree that the "+" isn't particularly telling,
especially so when it is underlined as the Active Letter.

I do use this button daily, however, in the PMS I have to
work with.

> 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?"
> >;- )

I am not adverse to listing that as a todo.

>>> What approach could most suitably allow a "removed" item to be re-
>>> examined?
>>
>> A removed item is gone. That's why it got removed. It is
>> copied to the audit table, however.
>
> but not accessible to plain users any time soon

The approach would be to have a "source" switch at the top:
"current waiting list" vs "previous waiting list entries".

>>> (or v11 with fixups)
>>
>> no

(on account of not being intended to have such changes)

> 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?

Such must be defined by local policies - perhaps upon
completion they must move it to a zone "Dr.Busser/done" for
you to attend to and remove the item. Other sites may have
other policies. It is not for us to decide.

Use case example: When I finish seeing a patient I set the
comment to "done" (well, "fertig") and one of the senior
partners double-checks the record and removes the entry from
the waiting list. (to keep with the truth, in 99% of cases
they are looking after the billing information I entered
... ;-)

At the end of the day it all depends on local use policy.
Nonetheless there's room for improvement, as always.

> 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 :-)

OK, let's assign any enhancement to "future" :-)

>> If the dialog was placed appropriately.
>
> Earlier list answers about where overlapping dialogs could be placed  
> suggested we had limited if any control.

Oh, we do have control but it is a lot of work to exert it.

>> I would have read the task *before* activating+ the patient ?
>
> 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.

I can fully relate to this scenario. That is why I emply
"Activate" until I am satisfied that I am done and can now
"Activate+" and give a last glance over it.

>>> post-search setting) across multiple different patients. However  
>>> there is
>>> no way in
>>>     GNUmed > Preferences > User interface > Patient search > Initial  
>>> plugin
>>> to "unset" a selection which would be the way I think this could be
>>> handled. Wishlist? Difficulty?
>>
>> That's an idea. Wishlist, yes, medium-complexity I'd say.
>
> +1 ?

42 :-o

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346