Re: [Gnumed-devel] Lab import (data) matching

[Karsten Hilbert]

> > IF the lab is known to make such mistakes I wouldn't trust their data
> > to be auto-matched later on eiter. If a particular use case really
> > calls for keeping around the lab's idea of what name a patient should
> > bear I'd store it as an external ID of type, say, "lab specific  
> > name" including the responsible lab as issuer.
> 
> The main situation that we can expect is when a patient is registered  
> in one system using their first name, but in another (e.g. lab)  
> system uses their second or warrior name. It is not necessarily to be  
> considered a "mistake" of the lab.
True enough.

> Both are valid names of the patient, and so maybe we agree the  
> solution is to keep the patient's known (multiple) given names in the  
> first names field, and to allow smart matching to any of these given  
> names, when appropriate.
Oh, this is done already by the Python matcher. It also matches on
previous names.

> The commonest use case for *appropriate* creation of a new identity  
> is when the patient would change their name first outside of GNUmed,  
> for example if they got married or otherwise changed their name  
> legally, and a new message (lab result) came into the praxis before  
> the patient came in to the praxis and got the new identity added, and  
> made into their default, in GNUmed. Think "standing order" for any  
> tests, or the patient getting care somewhere else with a copy sent to  
> their family doctor.
Sure, this is the precise use case why we support multiple names with one
active one. It's just that the importer won't know the difference
between lab error and "actually correct" when the new name doesn't
exist yet hence it needs to classify "unmatched with candidates".

Karsten
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger