Re: [Gnumed-devel] Gnumed's design suitable for complex encounter requirements

[Karsten Hilbert]

On Thu, Dec 31, 2009 at 07:09:38AM -0300, Rogerio Luz Coelho wrote:

> On the matter of phone calls and the multiple instances of GNUmed:
> 
> I really think this might be a solution, but not a very good one. GNUmed has
> the ability to store in the database with multiple intances, all running at
> the same time (thank Karsten for that forsight), but multiple instances
> would be burdensome and could get rapidily cluttered
> 
> Use case: say the physician gets cot up in a emergency and say another one
> just happens to come in, and he needs to see a exam in a 3rd walk in to sort
> out if it is or not yet another emergency ... sudenly he has 5-6 instances
> of GNUmed opened and it would take sometime for him to navigate between
> them, and then see if all of them are saved and acconted for...

Maybe I am not a typical user but I regularly work with up
to 4 instances of the PMS at my place of work. It doesn't
seem to cause any trouble. *Very* occasionally a form is
generated for the wrong person. Within those cases *very*
rarely this is not detected right away by either patient or
front desk staff. However, the possibility for error does
exist.

> My thoughts (although as always I haven´t the slitest idea on how to make
> this feaseable ;) would be GNUmed to open TABS, with the patients name as
> headers. This seems a lot more convenient, and would make for the same basis
> as multiple instances, no?

It would most certainly be convenient. It would make for a
lot more complicated coding, however, as a few of the basic
assumptions will need to change, say, from:

        there *can* only ever be a single active patient object

to

        within one sub-process there *shall* only be one active patient object

This change of assumptions opens up the box of pandora for
horrible programming errors which are extremely hard to
detect: data written to one patient really belonging to
another one - without it being the fault of the user (and
thus correctible by the user, IOW, it will happen every so
often without the user being able to do anything about it
short of not using the multiple-tabs feature) !

> And if we could make GNUmed get TABBED all sorts of new frontiers would open
> up for us (tabs with different colors could get assigned to diferent types
> of encounters, priorizations, saved / not saved diferentials, etc... )

However, the use of tabbed per-patient windows is certainly
useful.

In fact, tabbing is so useful that (IIRC) KDE is working on
an external-to-the-app tabbing feature where you can tell
the window manager (kwin) to create a meta window around
applications and bind each of their frames/windows/popups to
tabs of that meta window. Supposedly it will be possible to
tab together windows of *separate* apps, too.

I wonder whether it will be possible to use that meta window
to tab together several instances of an app by defining a
"group" of apps or something similar.

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