Re: [Gnumed-devel] demographics.sql

[Karsten Hilbert]

> > > In answer to Jim's question, PUPIC is 
> > IMHO also reconstructible. Hence constructed from constant
> > values (gender ISN'T one of those). Eye color still is, date
> Well, eye color is a somewhat subjective parameter, at least if the color is 
> a mixture like grey/blue/brown.  
Well, true. But we just need to ask the significant other :-)

> > of birth is, country of birth at time of birth is. It needn't
> > (and IMHO shouldn't) be an arbitrary number.

> IMHO no list of easily assessable low-level biometric
> parameters (i.e. eye color etc. instead of fingerprints, eye
> scan) will be sufficient to create a unique ID,
Not guaranteed to be unique but more likely to be so compared
to last-first-DOB only.

> plus you cannot assess them retrospectively.
Sure can but you'll need someone knowledgeable re the patient
in question. I didn't say "reconstructible without the
patient" either.

> I guess that a combinaton of
> assigned parameters (name, birthdate, social security number
> etc.) will be a much better choice,
Certainly, I propose to base this on:

- full name at birth
- date of birth in Gregorian Calendar
- country of birth at time of birth
- mothers name at birth
- ethnicity

However, this falls down in the following cases:
- "useful" name only assigned later in life (eg. China where
  rural poor kids only get their full name when entering
  school)
- indigenous peoples where a some names are very common and
  widespread such that even the mothers AND the childs name
  are not unlikely to be identical, respectively

Hence, I suggest to add a field "arbitrary data" where some
sort of unique attribute can be stored.

And then we need to turn this mess into a string.

Perhaps we can just use a text field and separate fields by
newlines with a given mandatory order of fields leaving blank
(not omitting) unknown values ? This isn't relational at all
(which in turn would call for a traits table) but solves the
problem we are trying to solve, IMHO.

It's not like we are trying to solve the UUID problem for the
world population but rather we try to make reasonably sure
that we can re-identify and merge data from disparate
databases. This is the basis for FEBRL to be able to work at
all.

BTW, how did the National Cancer Registry at Cologne (or
better yet, that of the former GDR) do it ?

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