Re: [Gnumed-devel] PUPIC etc.

[Karsten Hilbert]

> > This is probably the gravest flaw in our notion of distributed
> > databases/services:
> > 
> > IF we allow arbitrary (eg unconstrained) collections of
> > databases making up a network or services we MUST NOT allow
> > arbitrary (eg abstract, meaningless) patient identifiers. Else
> > we cannot associate data from disparate sources reliably.
> I see two general use cases: 
> a) the distributed service is gnumed-aware, e.g. some part of gnumed (own 
> demographics-server, etc.)
>  -> then we can use a gnumed-only patient-ID

a) what is a gnumed-only patient-ID ?
b) we cannot just use the identity.PK value

The problem with b) is this: Say, I have my
clinical/demographic database in my own practice. However, the
radiologist next door has a badder machine, sniff, such that I
host my documents database on his hardware. Now my practice
burns down. I don't want to be forced to restore my
demographics database in such a way that the patient PKs
magically match the retained and linked PKs in the documents
database at the surviving radiologists place. I want to be
able to re-link based on verifiable criteria as enshrined in
the PUPIC. Yes, this may involve having to interrogate each
and every patient at the next consultation. And this is with a
gnumed-aware service.

> b) the distribute service is not gnumed-aware, e.g. proprietary 
> databases/other EMR-software/whatever
>  -> then we won't be able to link patients using one single unique ID 
> (=PUPIC) for all services. 
That is true and adds to the problem.

> > This is where the PUPIC comes in. And this is why
> > xlnk_identity contains the fields pupic and data.
> Case b) IMHO whould mean we need some way to have one ID per not-gnumed-aware 
> distributed service (either in xlnk_identity or in some other table).
Yes, and this table is called ext_person_id :-)

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