[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Demographics schema - urb postcode not null
From: |
Jim Busser |
Subject: |
Re: [Gnumed-devel] Demographics schema - urb postcode not null |
Date: |
Fri, 07 Oct 2011 16:28:24 -0700 |
it is both possible (and apparently a notorious problem in some US states) that
you can have two towns or cities which are known by the same name, despite
being located in the same state or province, for example as documented here:
http://talk.collegeconfidential.com/parent-cafe/770966-why-do-some-states-have-two-towns-same-name.html
http://answers.yahoo.com/question/index?qid=20080731135833AAfaZFR
http://en.wikipedia.org/wiki/Middletown,_Pennsylvania
This means that when a person would select a street, even the combination of
street name, dem.urb.name
does not (unambiguously) confer on the street any geographic meaning.
I recognize it is possible that you could force a user to choose
which Mountain View, California or
which Middletown, Pennsylvania
from a list of two or more, but I continue to have a hard time with the idea
that a city (which may have multiple postal or zip codes) has a 'default'.
Removal of the requirement for postcode from urb would lose nothing presently
because
1) a city has no single (granular) location, it has a bounded area
2) it has potentially multiple postcodes
3) it is really only at the level of the street address that we achieve
anything close to a point location. For the purposes of delivering mail or
packages or sending an ambulance to get a patient, we need the granularity of
what is in their address anyway and presently the client enforces the
requirement to provide a postcode at the level of street (when inputting an
address).
What this relaxation would then also achieve is to not have to choose which
among
multiple cities of same name in same state or province
because the city name is serving only as a crude grouping term, and you could
always select patients of interest by their required-to-be-inputted
street-level postcode or zip.
If you do not want to relax the constraint on dem.urb.postcode, then how about
to relax the 1.0 client which presently requires to input a postcode at the
level of address / street, reasons being:
1) the backend does not demand a street level postcode
2) I personally rarely send letter mail to patients, and so forcing me to input
postcodes is extra work for minimal gain
3) if I later needed the postcode to send something to the patient, I could
look it up
-- Jim
- Re: [Gnumed-devel] organizations, Jim Busser, 2011/10/07
- [Gnumed-devel] Demographics schema - urb postcode not null, Jim Busser, 2011/10/07
- Re: [Gnumed-devel] Demographics schema - urb postcode not null,
Jim Busser <=
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Karsten Hilbert, 2011/10/07
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Jim Busser, 2011/10/07
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Sebastian Hilbert, 2011/10/08
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Jim Busser, 2011/10/08
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Karsten Hilbert, 2011/10/08
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Sebastian Hilbert, 2011/10/08
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Karsten Hilbert, 2011/10/08
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Karsten Hilbert, 2011/10/08
- Re: [Gnumed-devel] Demographics schema - urb postcode not null, Jim Busser, 2011/10/08
Re: [Gnumed-devel] organizations, Karsten Hilbert, 2011/10/07