Family History
The handling of family history in version 0.3 of GNUmed is described in an archive message dated ~ August 23 2008 from James Busser with subject line Re: fields in health issues
here
An earlier archive message from 2006
here provides some idea how Family History may be handled once we are able.
The archival message is, by the way, outdated on the question of allergy support... we use a double approach: explicitly model known-ness of allergic state as well as storing actual allergy data. There is a trigger syncing the two tables with each other.
The technical notes below had no better place. Suggestions accepted.
>
It seems to be a single table.
Yes, so far. We may want to add a link to a relationship_type
table but that does not change the general concept.
The current, enhanced layout was posted to the list by Karsten as "Family History Table" Thu, 17 Mar 2005 18:06:51 +0100
>
I do not some sort of ?external key (fk_relative??)
Yes, fk_relative
can point to another identity in the
database. It's
either fk_relative OR relative_name and
relative_dob but not both.
>
One of the major bugbears of my system is the inability to import family
>
history data from within the database from related persons, although when I
>
set the tables up which I've shown you before (and enclose below), they were
>
normalised to do so, I never got it finished.
>
>
This has caused endless unnecessary repeative copying from one instance of my
>
program to another - instead of being able to have an import wizard come up
>
with all related family members and let you click on a checkbox to include a
>
particular history problem in the persons notes you are working on.
Ah,
that is how I know Richard talking design
>
Have you included this ability in your table design?
I
should think so. For one thing we have the ability to
store links to relatives (independant of family history).
Also, we can directly
point to a relative
from fHx.
There are two conceputally conflicting design goals (that I am aware of).
1) family history item integrated into a patient's EMR
- searching a patient's EMR for family history narrative is easy
- a condition of my grandparents can be of significance to
my health but not to that of my sister (gender-wise)
- may require repeated input of the same condition when
linking to different patients unless intelligently
supported by the frontend
2) "generic" family history item outside any patient's EMR
- can be linked to from several EMRs since my grandma
may suffer a hereditary disease no matter whether that's
linked to me or my sister as a family history item
- requires non-neglectable hoops to jump through to allow
for appearance in searches over the EMR narrative
Now, what are the suggestions here ? I am feeling like
favouring 1) at the moment.