[Gnumed-devel] Re: schema choice - patient names, aliases, duplicates and merging

[J Busser]

On Sunday, December 21, 2003, at 06:23 PM, address@hidden wrote:

> From: syan tan <address@hidden>
> Subject: [Gnumed-devel] schema choice
>
> apart from licensing,  what do people think of tables that show one 
> "trait" e.g. a person's sex, birthdate , name ,address is a variation
> of a trait row, and trait row's might be recursive ( e.g. names, ).  Is 
> it going too far with the object side of a o-r mapping ? Would it impair
> the performance a lot ? ( say 10,000 patients x 20 traits, 200,000 rows 
> ; server holds onto a connection and makes a batch of 20 sql retrievals 
> per patient access request from one client).

Syan's question included name and sex which made me wonder how it is proposed to handle:

- patients undergoing name changes where it remains helpful for their other "aliases" to remain indexed
- patients inadvertently duplicated (doubly-entered with duplicate, or variant, name spellings and birth dates) who are later realized to have multiple encounters/transactions on file under different identities which require a "merge"
- when creating a record (e.g. for a new patient), is there a useful distinction between the *fixed* properties that identify an individual (birthdate and USUALLY their sex and name) versus "variable" properties such as their phone numbers, addresses, health insurance numbers - some patients requiring multiple contact numbers. addresses, health insurance numbers to be stored
... also, I have been impressed with the look-up value of a telephone number, for example when renting a movie at the local video store ---> it would be much easier and clearer option for office staff to obtain a phone number from callers (or from call display) especially where the caller (patient, patient's family) has poor language fluency... we have a large immigrant population, also tons of patients with the same last name and even first name or at least initials!

The above affect how patient uniqueness is maintained while keeping it easy to find them AND distinguish them from each other. If this is already well developed and documented anywhere can anyone direct me, else may it be of value/interest to discuss in a thread, or is there a point person leading this service/module with whom I should exchange questions/ideas offline?