Re: [Gnumed-devel] Mock up of Potential Patient Data Entry screen

[Horst Herb]

On Thu, 9 May 2002 00:22, richard terry wrote:
> -Demographic screens always tend to be difficult to design and a bit of
> a dog's breakfast

It is, but your design is certainly way more eye catching and functional 
than my original one. How does it look at 800*600 which is our minimal 
size ?

A few considerations:
* there should be no "street1, street2 ...". There should be one multi line 
text widget that does not limit the number of lines.
* while I agree that the two most common options "phone (h), phone(w)" 
should be displayed in that way, there should be a button "more" fot other 
phone numbers. With people like me you would have a hard time catching me 
under just these two numbers, especially since I live in an area with zero 
mobile coverage
Same with the address: we need the "more" button for more addresses; plenty 
of people live part of the week "here", other part of the week "there"
* I would move the date of birth up to the name. australia is the only 
country I ever worked in where the date of birth does not play an utmost 
important role in identifying the patient, and it's about time that we 
start about getting that right too. Should become a habit for anybody to 
ask "name & date of birth" instead of "name & address" first thing, as the 
latter is highly variant

> -We will really need different screen designs per country as the billing
> proceedures and information needed will be different

plugin!  We divide the screen real estate in "sizers". Whatever major 
entity (like "billing") does not fit into the available screen estate (for 
countries where it is even more complicated than in Oz), should 
automatically create a new "notebook" page and place itself into the new 
page.

> eg. our national ID number is the medicare number, we have card
> concessions etc, we often use a note system called the RACGP system for
> paper notes (yes I know that gnuMed is meant to be paperless!!!!
> eventually!!!!! but I included it as an interim anyway).

I would chose a text field for the ID number, followed by a combo box 
displaying the type of ID. That way, you can have:
- national ID (if applicable)
- practice proprietary ID
- ID's in other practices / hospitals (the RMH & RCH always asked me for a 
patient's hospital ID if they had been seen before, sped up phone calls a 
lot)
- Medicare
- DVA
- Pension
- and even VISA card no in one single widget, saving not only valuable 
screen real estate, but making your "ID" options virtually unlimited

> -VB is much easier to prototype then Wx!!!! (for me anyway)

The continue designing in VB - just make sure you try it out in different 
resolutions (pity VB is not really up to scratch when it comes up to 
making auto-resizing dialogues)

> Comments welcome

Wonderful job! I will let the "download script" wait and rather implement 
the design in wxPython tonight

Horst