Re: [Gnumed-devel] family history table

[Karsten Hilbert]

> > The disadvantage is to have to jump through some hoops when
> > searching the clinical record.
> 
> Why? The fundamental thing about database is that normalising shouldn't make 
> any difference.
It sure makes a difference.

> The query across any number of tables just pulls out a single 
> recordset.
But you need to know which tables to query on beforehand !

What we are trying to achieve as much as possible is that the
user can say "show me all the patients for which I noted down
chorea huntington one way or another" and up pops a line
"patient X: chorea huntington found and, btw, this time you
wrote it down in Social History" instead of no line showing up
and the user scratching his head worrying whether he put it
down in Habits, Social History, Family History or Physical for
some patients and hence missing those. If the user then wants
to *exclude* some findings (eg "ignore FH") - that's fine.

> Remember in my table structure the linkage is between the Patient identifier 
> and the family member ID, so it is irrelevant how many Marthas are in the 
> system who are 'aunt', they can only be linked to the correct patient!.
Come on !

Patient A walks in: "My aunt Martha suffered a stroke at age 50"
Patient B goes: "My aunt Martha had a stroke sometime before 60"
Patient C like: "My aunt Martha had a stroke"

One Martha, two Marthas, three Marthas ? Each of which is
possible and can be equally wrong. Now it ain't terribly
horrible if we put in three Marthas while they are all the
same Martha in real life. It is a no-no, however, to put in
just one while in life there are three ! So, to be on the
safe side of things medically one would store one Martha per
patient (eg my design - not that I like it !).

However, I do see the value and beauty of not having the
Marthas stored directly in Mr.Smith's EMR. I do think a
well-designed frontend can make it hard for the user to not
think about differentiating Martha's properly by a) requiring
uniquifying data on duplicate entries and b) pointing out that
Marthas come in different varieties and therefore linking to a
pre-existing Martha may require careful thought as to the identity
of a given Martha. I can assure a) on the backend. I cannot
make sure b) is met.

> The family history is instantly available using both my schema and my screen 
> design. You never have to search the EMR to view the patients family history 
> at all - never.
Well, IF you know you want to display FH that's all fine. I am
thinking of the case where you don't know that you want that.

> I hear your comment below, however I think there is no excuse for bad table 
> design
I have never thought excuses for bad table design. I have at
times tried to weigh pros and cons against each other.

> and that is what has troubled me about much of the table design on gnuMed
If you notice any bad table design I should like to know about
that immediately. I shall be happy to improve it. But you'll
need better arguments than "oh, that's how I always done it
and it worked for me". One argument I will always listen to is
"That ain't gonna work because of ...".

> The example you give below is not unreasonable, however any good program 
> should have a user friendly gui-screen which will enable the user by a drop 
> down box tor text box entries generate queries which they can thenbe  stored.
Lest the programmers "forget" to include some exotic corner of
the data ("oh we never thought you'd ever want to search on
that"). I hate that and would really prefer to have all
searches on narrative to "just be there". Hence we use the
clin_root_item table.

Now, for something different, apart from my trigger solution of
duplicating data into clin_root_item from the family history
table there is yet another way: Include the family history
table into the "complete narrative" view which is there to
aggregate encounter/episode/issue names into the clinical
narrative for searching. It could just as well add in family
history (and other such information). Maybe that's better than
using a denormalizing trigger ?

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