Re: [Gnumed-devel] demographics editor

[Karsten Hilbert]

> Case1:
> 
> You have loaded a patient. You wish to see more details, so you flick to the 
> demographics tab - his data has been loaded in the background and is all 
> present.
This sounds OK to me.

> Case 2
> 
> You have loaded a patient. His clinical record is in the program. You need to 
> look up patient B's demographic records because someone is on the phone 
> asking about them.
> 
> Hence you have to be able to search for them. You click on the search button 
But before that you would change to another GnuMed instance
running on this machine - one in which you already finished
dealing with the patient and where you don't care that another
patient is called up. Where is the problem ?

I run 4 parallel instances of the commercial package we use
in daily practice. That works out nicely for me.

> on the demographic toolbar which is imported when you load up gmDemographics, 
> it clears all the fields. You are after Peter Smith. You can type in the 
> surname field smith, or say smith in surname, and peter in firstname, and 
> click the find button again - up will come all the peter smiths - you load 
> his details.
> 
> Now you have a situation with both patient A and Patient B''s records in the 
> same space - could be somewhat confusing.

How so ?

Either you *selected* the Peter Smith you were after to become
active - at which point he is the only patient visible in the
client.

Or you are in the demographic details tab where the top list
shows all the matching Peter Smith' along with a few details. Now,
this would indeed mean several patients are visible at once.
But wasn't that your very own design and suggestion ?!?
Unless you want to say that you don't endorse this suggestion
anymore...

> Plus this method of searching, though great if you wanted to pull out all the 
> peters, who lived in a particular postcode whose occupation was a soldier, is 
> slower than having a dedicated search textbox (one of course needs both).
What do you mean by "this method of searching" ?!? The method
of searching is that at any point in time I can type in a name
fragment or a number associated with a patient into the
"dedicated search textbox" inside the top panel and pull up
all matching patients. We don't have any other method of
searching for patients as of today ? In particular we don't
have a method of searching for "all the peters who lived in a
particular postcode whose occupation was a soldier". Unless
you refer to the totally generic SQL tab which is neither
intended nor coded for supporting selecting patients.

> That's why I prefer demographics to be separate from the client - at least on 
> its own full screen panel.
And that is why demographics is a whole-page notebook plugin ?!?
The always-visible top panel only shows name/age. I start
wondering which client you are talking about. After all it was
you who suggested showing more demographics in the top panel
(eg. street and urb). I didn't include that yet. We seem to
have a strange kind of disconnect here.

> In regards to a previous comment you made about how I stated I felt it 
> important to always have the patients details visible at the top of the 
> screen - ie contextural (plus the tabbed lists + scratch pad + reviews - 
> which BTW are in hibernation), I do, however what I don't beleive is ok, is 
> to have visual 'cross fertilisation' with other peoples records.
That would happen in the demographics tab *only*. And it
wasn't me who suggested that. I strongly believe in the "one client
instance == one patient" paradigm, so no problem there ...

> Anyway, Hope this explains.
It does explain some but I still remain befuddled.

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