Re: [Gnumed-devel] Sort-of intra-praxis messaging

[Jim Busser]

On 2010-02-03, at 2:59 AM, Adrian Midgley (Gmail) wrote:

> On Wed, 2010-02-03 at 00:32 -0800, Jim Busser wrote:
>> Pending a widget that would allow creation of an inbox message using the 
>> GNUmed GUI, it would be possible for a user to find themselves (because they 
>> would be a person who exists in GNUmed, even though they were not yet a 
>> patient) and presumably might be able to add themselves into the waiting 
>> list and could then attach a message to a suitable zone (e.g. a zone that 
>> related to a particular doctor).
>> 
>> Is the above workable, or does it violate the concept that a person must be 
>> considered to have become a patient once a related record is created in a 
>> clinical table and I believe the waiting list is a clinical table?
> 
> Keeping the master index as a _persons_ index rather than patient index
> is not an illogical general principle.  THen you use a marker to
> indicate type_of_person.

I believe the above is the approach, yet by borrowing a clinical table to serve 
a communication function when the communication may not concern a patient by 
side-effect makes one of the staff apparently a patient, that is why I was sort 
of asking if this was a bad idea.

The alternative would be to enable the creation of inbox messages within the 
inbox plugin:

        New (button)
        Phrasewheel field (for selection of target individual user)
        Information field (the message)
        Priority designator

enhancements would include:

        Edit button
        Delete button

but this would make sense only for "hard" inbox messages rather than the 
virtual ones that appear by virtue of unacknowledged or unsigned results and 
documents. It would also *mostly* make sense only when the originator could 
"see" the message after having committed it, since normally the inbox filters 
on messages relevant to the logged-in user. This might be made "controllable" 
by having the filter be determined by the value in the phrasewheel above, which 
would default to the current user.  Altering this value would alter the 
messages displayed.

Nobody would wish this other-user value to persist more than temporarily. If 
the concept is sound, I would suggest that on activation (on being returned-to 
or re-set into focus) the inbox would refresh the filter to take the value of 
the logged-in user.

The above approach would allow the originator of a message to later locate and 
edit (or delete it) as necessary. It would also allow a user to examine any 
inbox messages that might need to be proofed against anything critical on 
behalf of an absent colleague.

There is a possibility that some other user (staff) may have sent a private 
message intended to be confidential only for the recipient. Accordingly if we 
would implement such functionality as to be able to review the inbox messages 
of another user, I would suggest a field

        is_confidential

which, if set to yes, would conceal the display of the message in the list view 
(blank or clear or bulleted)... only be on opening the message would the 
content be readable.