Re: [Gnumed-devel] gmDemographics Question de vs au requirments

[Karsten Hilbert]

> 1) Name/Salutation/Surname/Sex/Title/Street (multi-line textbox)
>       - I can't see much variation in requirementss here
> 2) Birthdate/Marital Status/Country of birth/next of kin 
> textbox/relationship/search database button
>       - I can't see much variation in requirments here
> 3) Contact numbers:Home phone/work phone/fax/mobile/email/web
>       - I can't see much variation here
> 4) Photo - aquire/import/export/delete
>       - I can't see much variation here
I think I agree to this.

> 5) Record Save - will operate from save button on tool bar above window
Matter of taste but won't argue.

> 1) The suburb/state/postcode thingy:
> 
> In AU we need Suburb/State/Postcode as separate boxes (Why - because for 
It doesn't matter whether it's actually different input fields
as long as the are *handled* separately, eg. by parsing. It
is, however, easier to handle that by separate fields so I
agree. Could you expand on the "suburb" concept, however ?
That's rather unusual for us. We would usually have
postcode/urb/state in that order, eg. postcode would most of
the others in most ways.

> 2) Country specific numbers  eg Au- medicare etc.
> 
> Now with regards to gui-design we can incorporate this quite simply either by 
> a table in the backend saying what the field requirements for suburb etc are 
> per country
I would make the widget accept arbitrary number type/number
value combinations but have a table in the backend that defines
the per-locale default set of number types presented. In fact,
a phrasewheel on number type will likely do as a DE user us
highly unlikely to type "DVA" and wonder about any AU number
type coming up... It should, however, be possible to enter any
other number, too, eg. when caring for Richards' AU aunt when
she comes to my practice while on vacation in Germany (Thank
God we both run GnuMed so we can seamlessly transfer all
medical data to Richard's office later on :-)

> I also want to get the validating of data-input fields in place. I've talked 
> to syan about this and asked if he would help here. 
Please make sure to write general purpose validators that are
argument driven within their domain. Or even create dedicated
input fields (like gmDateTimeInput.py).

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