gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] design comments: demographics widget


From: Karsten Hilbert
Subject: [Gnumed-devel] design comments: demographics widget
Date: Fri, 9 Apr 2004 02:36:29 +0200
User-agent: Mutt/1.3.22.1i

Yes, patients, staff and (human) contacts *are* "lumped"
together. After all, they are all "persons". Yes, we can (and
should) have separate interface. And, no, they will not
display odd behaviour.

A patient will not show up in a contacts-specific widget since
it will have additional data in contacts-related tables that
define it's contact-ness. Same for staff.

Further, I don't understand the problem with "the user being
able to open patient files (charts, I assume) on their
contacts" ? Why of course! IF a "contact" calls me for medical
advice I open that "persons" *medical* chart (which in GnuMed
gets created on the fly courtesy of the very act of opening
that contact with a clinical widget IOW instantiating a
gmClinicalRecord). That precisely IS the beauty of it all, no ?

And no, we don't need to have a kill-all demographics screen.
We can have a mini-demographics screen for contacts that
captures the minimum-necessary data. And a demographics screen
for adding additional data becoming mandatory once a person
turns into a patient. Etc etc.

I am strongly opposed to moving patient seletion functionality
out of the top bar. This client is about working with
patients. If some plugin doesn't fit with that concept it
better have a darn good reason for being in this client AT
ALL (as opposed to in it's own one). If we remove
search/select from the top bar we can just as well start using
any of the much more generic application frameworks. The
GnuMed notebook plugin architecture IMO should ease the job of
writing and running plugins dealing with *one* currently-active
patient. That's a design decision. That's precisely what our
reference client is all about. We also, for good measure,
don't allow dealing with more that one active patient.
Additional persons can and will have to be searchable, of
course and be it just for connecting relatives only.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]