Re: [Gnumed-devel] demographics editor

[Richard Terry]

To explain in a clearer manner regarding  the integration of the gui-stuff.

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.

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

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

That's why I prefer demographics to be separate from the client - at least on 
its own full screen panel.

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.

Anyway, Hope this explains.

Thanks

Richard

On Mon, 13 Sep 2004 01:54 am, Karsten Hilbert wrote:
> > Now I feel REALLY BAD! and It's sunday and I've come to work specially to
> > pick up the gnuMEd mail!
>
> Sorry for that.
>
> > Not true. I just don't think the design of the current GUI with its
> > multi-layered tabs is functional, but is very confusing.
>
> It is certainly fine to strive for better designs. It's
> equally fine, however, and important, too, to eventually get
> something *done* even if that means not yet going for the nice
> wxPython 2.5 or putting up with a not-so-perfect 0.1 UI
> concept.
>
> > > I have accepted that the current demographics editor is what
> > > we'll have for entering AND changing patients. So be it.
> > >
> > > Am I correct that there needs to be a "clear fields" and a
> > > "save data" button on the toolbar for the editor ?
> >
> > Clear fields only takes place on either:
>
> OK, I would have labelled "add patient" as "clear fields" but
> it's much better to have an implicit clear_fields from add_patient
> rather than the other way round.
>
> > the add new patient on the popup menu - you can use the popup menu for
> > now until I do the toolbar hopefully next week.
>
> Ah ! Didn't think of that :-)
>
> > > > 1) The add patient button is clicked
> > >
> > > Where do I find this button ?'
> > >
> > > > 3) The user the clicks on the save button
> > >
> > > Where is this button intended to be at ?
> >
> > See above - I'll have to re-do a toolbar
>
> Got it.
>
> > > Uhm, uh, I thought one of your design principles was to aid
> > > the memory-impaired in remembering which patient they are
> > > dealing with in a given client instance ?
> >
> > Yes, but not in this format. Personally I prefer a stand alone client to
> > do things like administering the demographic database. The reason being
> > that implanting the demographics functionality within the gnumed window
> > itself I feel becomes confusing.
>
> I am not sure I understand this. We have *very* basic patient
> demographics in the top panel which is shown at all times.
> This information is IMO necessary to know which patient the
> client is set to work on. I don't understand what you mean by
> "implanting the demographics *functionality* within the gnumed
> *window* itself" (emphasis mine) ?
>
> >  Unfortunatley for some reason gmDemographics will
> > not run within gnuMEd on my machine any more
>
> It runs on mine after I fixed some things like 2 or 3 days
> ago. I did work on the saving code a while back, broke it but
> fixed it again - it seems to work here ? I may have to double
> check but if you mail me a --debug log I might be wiser.
>
> > > Or in other words since the current state isn't nowhere near
> > > the (as yet undefined) state that you need GnuMed to be in to
> > > use it (which is fine) we should switch tools and thereby a)
> > > break existing installations and b) make it lots harder for
> > > Debian people (unless I am mistaken) ?
> >
> > How come its harder for debian people.
>
> If I am not mistaken Debian does not ship wxPython 2.5.
>
> > No-one will using gnuMEd in a production sense for some time as far as I
> > can tell.
>
> I don't understand why you keep ignoring existing deployment.
>
> > I"m using debian (though
> > I do prefer ARCH) cause I couldn't get egenix to work on my ARCH box. I
> > can still run 2.4 independantly from 2.5, so it shouldn't upset anything.
>
> Sounds like I am wrong. Someone with better knowledge please
> speak up on whether 2.4 is in stable or at the very least
> testing ?
>
> > Also,
> > anyone currently playing around with gnuMed must have considered linux
> > knowledge, otherwise they wouldn't have got the thing up and running in
> > the first place.
>
> They may not even run Linux. The installation that we use
> doesn't. And they certainly don't have Linux knowledge. They
> make us (eg. Sebastian and me) have the knowledge.
>
> > Anyway, I'll try and do a toolbar for demographics in the next few days
> > and mail it to you.
>
> Thanks,
> Karsten