[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] demographics.sql

From: Hilmar Berger
Subject: Re: [Gnumed-devel] demographics.sql
Date: Mon, 15 Mar 2004 22:03:08 +0100

On Mon, 15 Mar 2004 19:23:46 +0100
Karsten Hilbert <address@hidden> wrote:

> Not guaranteed to be unique but more likely to be so compared
> to last-first-DOB only.
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 ...
> > 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
In Germany, in the majority of the cases, this will boil down to full_name, 
dob, place of birth, mothers name, german. The entropy of "country/place of 
birth" and ethnicity might be quite low in some settings (only local patients 
of same ethnicity. 
> Hence, I suggest to add a field "arbitrary data" where some
> sort of unique attribute can be stored.
Sounds good. Maybe in some countries this might be the only way to identify a 
patient, especially if there are no assigned numbers and the concept of 
different names and dob are not well established. 

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

> 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.
IMHO, there will be no way to have one schema of patient identification that is 
valid for all
possible settings. We will certainly need more than one widget/form to enter 
identification data and specific methods to map those to a internal (at least 
local) patient ID. Which might be the same as PUPIC.

If all this is suitable for FEBRL or not - I don't know. At least in Germany it 
wont be allowed to aggregate data without previous informed consent of the 
patient. An as you have to ask the patient anyway, you usually assess some 
identification data (name + dob) that can be matched to other data at the same 
time. Eventually, you will have to take those identification parameters that 
are present in other data sources as well, so normally you will have not much 
more than name + dob. But I believe that getting informed consent for every 
data source (this is mandatory at least in Germany) is much more complicated 
than matching the data sets in the end if you have at least name + dob. 
> BTW, how did the National Cancer Registry at Cologne (or
> better yet, that of the former GDR) do it ?
As far as I know, name + dob, maybe plus place of birth or something similiar. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]