I'm not quite sure what we are talking about here. Is this thread about identification of patients as in "Mr. James Kirk, health-insurance-no ENTERCARE-2800-03" or "hong,chinese male, 2 years old, long nose, nice mother" or are we talking about IDs (=numbers) used to identify patients across databases ? These are two different concepts, IMHO. I assume we are talking about the former but maybe you want to combine those two ...

Good point. I think we are talking about this:

1) gnumed-internal patient record primary key

• this we got handled with identity.id
• we use this inside one database for foreign keys
• we do use it across services via xlnk_identity
• we cannot, however, rely on the latter

2) to alleviate the latter in 1) we need

• an identifier with meaning for use across databases
• suited to computation (eg. defined structure, not just arbitrary free text)
• human readable, however
• short, concise format
• which to me is the GNUMed PUPIC

3) the GNUMed "internal" Patient ID

• this is just some assigned identifier within one "GNUMed eChart system" handy for referring to patient eg, the primary key of a patient can change across dump/reload of the entire database
• the GNUMed internal Patient ID cannot, however
• easily done via ext_person_id rows

A possible order of importance is like this

1. full name at birth
2. date of birth (Gregorian calendar)
3. mothers name at birth of person
4. ethnicity (see note)
5. country of birth at time of birth (see note)
6. arbitrary additional data field, perhaps social security number or other locally meaningful data item

Notes: - 4) and 5) only really start to be useful in countries with high percentages of first-generation immigrants... ethnicity being placed before country of birth, since second-generation immigrants (now of "local" country) are often still of original ethnicity. - inclined to move from cob to pob (be that place a celestial body, country or township), perhaps with subfields. - arbitrary data field may be important to countries in which there may be no assigned numbers and the concept of different names and dob may not be well established - "useful" name may 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

• 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 ?

GnuMed PUPIC design requirements:

• variable length fields
• delimited by #
• no leading/trailing spaces

fields proposal: 1) own full name at birth - in locally used language 2) date of birth - in Gregorian Calendar units 3) mother's full name at birth of child - in locally used language 4) place of birth - country or town 5) ethnicity 6) arbitrary data

-- JamesBusser - 21 Aug 2004