Re: [Gnumed-devel] gmDemographics

[Karsten Hilbert]

Aha !

Now I finally understand the worries about the partial
duality in the interface.

To me Richard's notebook plugin isn't THE (only) patient
plugin. Remember that we can easily (well :-) configure which
plugins to load into the notebook so in some rooms we'll load
just a few patient related plugins, different ones at the
frontdesk, different ones yet at the in-house lab or X-Ray.

Hence, I don't see a problem with having more than one patient
related notebook plugin. Yes, we currently have duplication of
functionality but, hey, we can afford that :-))

To me the day-to-day patient search widget is the top-left text
field. The patient selector notebook widget, however, has it's
merits, too: it can be extended to a demographics/patient
*management* widget, displaying family trees, merging
patients, etc etc. In short, working *with* patients (not the
plural) while the top-left field is for *selecting* the
*active* patient. The notebook patient management plugin could
feature a button <make active> to make the currently selected
patient the active one.

> > Is there a particular reason why it is not directly used as a
> > WholePage plugin in the main notebook ?
>  Largely historical (pretty sad for a project that hasn't reached
> alpha yet ;-)  
Nothing sad about history there :-)
It shows that we worked on things.

> There is some rationale, as Richard's widgets largely relate to a
> patient: allergies, scripts, recalls, etc. whereas Horst's don't: Python
> shell, SQL shell, etc.
I do not think this to be a valid rationele in light of our
client. As we are able to configure loaded plugins it is
possible to "theme" clients by configuration.

> BYW, By this logic, your document viewer should go inside the Patient
Not *should* but *can*. And, yes, it is retargettable. It can
be run standalone, as a notebook plugin or placed anywhere you
wish including inside the patient manager window as it is just
a panel holding a tree control.

> Window (if you've done it differently, it doesn't matter, the changeover
> is easy)
Yes I did and for a reason: typically one would configure a
particular client for archive use only; scanning, indexing,
viewing.

> "Patient search" probably should be a separate tab, as it doesn not
> relate to *a* patient. The advantage of this  is multiple instances of
> Richard's interface to reflect multiple open 'patients' (we need to
> rethink the messaging for this though) Then PatientWindowManager can
> become the elusive "patient object".
I would strongly object to several patients being "open" as in
"currently active" in one instance of GnuMed. If you need that
start another instance. It is useful to be able to *work* with
several patients (waiting list, merging patients, calculating
genetic disease propagation risks) but one patient should only
ever be the active one. To me it seems clear to make the
distinction: One window == one patient.

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