|
From: | J Busser |
Subject: | [Gnumed-devel] Re: schema choice - patient names, aliases, duplicates and merging |
Date: | Sat, 27 Dec 2003 01:36:45 -0800 |
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!when creating a record (e.g. for a new patient), is there a usefulWhy of course. What else use would it be to stick to an RDBMS?
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.
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, orWell, yes. No code there yet, of course.
variant, name spellings and birth dates) who are later realized to have
multiple encounters/transactions on file under different identities
which require a "merge"
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.
[Prev in Thread] | Current Thread | [Next in Thread] |