[Top][All Lists]

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

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

From: J Busser
Subject: [Gnumed-devel] Re: schema choice - patient names, aliases, duplicates and merging
Date: Sat, 27 Dec 2003 01:36:45 -0800

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 etc.
Why of course. What else use would it be to stick to an RDBMS?
Just making sure... Syan Tan's proposed support of traits seemed to include in the same table both fixed and dynamic (sometimes multiple) properties of individuals. I was thinking it might be useful to maintain these in separate tables, fixed being more likely intrinsic to the individual --- name, dob and sex usually being fixed ;-) --- with dynamic properties (e.g. addresses) better thought of as associations. If traits are meant to include hair color etc maybe this is better recorded as part of a physical exam. Traits did also make me think "genetics" but I cringe at that thought!

You need to read the schema, particularly the tables identity and names.
Yes, as soon as I manage to get on board with CVS

- 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"
Well, yes. No code there yet, of course.

We already have sort of a white paper for assigning a PUPIC. No one's got
around to putting forward a real proposal or even code on how to actually do
it. Please feel free to share your ideas on the list.

Can I be pointed to this white paper... didn't recognize it on the white papers list at
reply via email to

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