[Top][All Lists]

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

Re: [Gnumed-devel] Family History tables

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Family History tables
Date: Wed, 8 Jun 2011 23:14:40 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Providing a .family_id field is not a problem at all,
technically. But it's a quagmire regarding actual use:

Say, my parents have a family history of diabetes.

I do want to have the same .family_id as my parents do.

Say, may wife's family has a family history of stroke.

My wife does want the same .family_id as her parents do.

Now, I don't have a changed risked of stroke because of my
wife's FHx.

My wife does not have increased Diabetes risk because of my

Thus we both do NOT want the same .family_id because we
don't transfer risks to each other.

So far so good.

What about our children ?

Which .family_id do they get ?

Do they store both ?

How many (and which) does the third cousin of my paternal
aunt's husbands stepchild store ?

The problem with this is that "family" is not at all a
well-defined entity - not without attaching very
thought-through context.

Other than that .family_id also has confidentiality
implications but those could be overcome by judicious use of
asking the user whether they want to link certain items or

So, while .family_id seems like a neat, obvious, and
intuitive idea it really is not AFAICT.

However, I still can't decide whether to make each FHx entry
a new row or share such entries among relatives.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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