gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] demographics editor


From: Richard Terry
Subject: Re: [Gnumed-devel] demographics editor
Date: Mon, 13 Sep 2004 19:37:43 +1000
User-agent: KMail/1.5.4

see comments in body below of text below.

I give up on this one.

Regards

richard

On Mon, 13 Sep 2004 06:32 pm, Karsten Hilbert wrote:
> > 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 ?

Plenty of problems. THE biggest mistake made in AU computing that I can see is 
wrong information put into wrong patient, and wrong scripts being printed for 
the wrong patient. The latter always gets picked up by the pharmacist, 
because in AU you have to show you medicare card before you can get your 
drugs, but the former is a real nuisance and virtually untraceable. That it 
happens I can attest from both my own and others and chemists experiences.

Having multiple clients open with multiple patients is asking for trouble. Not 
saying that I don't do it, or that we won't do it, but its asking for real 
trouble unless a lock is immediatley put on each unattended client (not sure 
how you'd do that) requiring a positive ID to re-enter those records.

Next problem is time. Having to load another client, just because you want to 
look up a different patients address is a pain in the bum, compared to a 
single click on another tab etc.

>
> 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






reply via email to

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